Eclipse Community Forums: EGit / JGit

Help

Home

Home » Eclipse Projects » EGit / JGit » Rebase quirk(Explicit rebase v implicit rebase via pull)

Show: Today's Messages :: Show Polls :: Message Navigator

Rebase quirk [message #957856]

Thu, 25 October 2012 14:50

R Shapiro

Messages: 386
Registered: June 2011

Senior Member

I just noticed a rebase oddity in EGit 2.2. Not sure whether or not it should be considered a bug.

The short summary is that if there are conflicts in a rebase, a direct invocation of the EGit rebase command behaves differently from a rebase invoked via 'pull' + branch tracking.

So suppose I create a local branch that tracks master via rebase. In other words I tell EGit to make a new branch from master and in the dialog I select the 'Rebase' radio button. Suppose further that I commit conflicting modifications in these two branches.

Now I want to rebase my new branch on master. There are two ways I can do this:

1) I can invoke the EGit 'rebase' operation and select master as the target.
2) Since my new branch is tracking master via rebase, I can also use EGit 'pull'

I would expect the same behavior EGit behavior either way, but this is not what I see.

If I follow approach (1) I get the standard EGit 'Rebase Result' dialog telling me the rebase was stopped due to conflicts. I can then proceed in the usual way: resolve conflicts, stage, and continue until I'm done.

If I follow approach (2) something different happens. I get a simple 'Pull Result' dialog telling me the rebase has stopped due to conflicts, not the Rebase dialog. The conflicting files are marked in the Explorer but the comparison view does not flag conflicts and the 'continue' rebase option is never enabled. To get out of the rebase state I have to use 'skip' after staging all the fixes, though of course I'm not skipping anything. It's all very misleading and confusing.

Report message to a moderator

Re: Rebase quirk [message #960434 is a reply to message #957856]

Sat, 27 October 2012 13:30

R Shapiro

Messages: 386
Registered: June 2011

Senior Member

I think this should almost certainly considered a bug, unless the development team specifically wants this odd behavior for some reason.

In the meantime my strong recommendation is that if you encounter a rebase conflict on pull, immediately abort the rebase. Then restart it using the standard EGit rebase operation to get reasonable behavior.

Report message to a moderator

Re: Rebase quirk [message #965968 is a reply to message #960434]

Wed, 31 October 2012 16:53

R Shapiro

Messages: 386
Registered: June 2011

Senior Member

A little more detail on this, which at some point I'll file as a bug:

Part 1: First create and switch to a new branch that tracks master via rebase:

1) Open the 'Branches' dialog to create a new branch.
2) Select 'master'
3) Click 'New Branch...'
4) Enter 'egit-rebase-error' as the branch name
5) Click the 'Rebase' radio button in the 'Pull Strategy' section
6) Click 'Finish'

Part 2: Create some conflicts

1) Edit any two files
2) Add and commit the changes.
2) Open the 'Branches' dialog and switch back to master
3) Edit the same two files file in master that as were edited in (1) such that conflicts are created.
4) Add and commit the changes

Part 3: Demonstrate the bug

1) Open the 'Branches' dialog and switch back to egit-rebase-error
2) Invoke the EGit pull operation. Note that the first conflicted file is decorated as such in the Explorer view.
Expected: The EGIt rebase conflict dialog, leading to the merge view selection dialog.
Observed: A different dialog, and no way to get to a merge view
3) Resolve the conflict in the first file by editing the file and staging the changes. This is already problematic since
there seems to be no way to get a merge view. There are difference markers in the file but no conflict
decorations to distingish conflicting from non-conflicting differences.
4) Stage the manual conflict resolution from the previous step.
Observe that the first file is no longer decorated in the Explorer view as conflicted, as expected.
5) Continue the rebase.
Observe that the standard EGit rebase dialog finally appears!
Observe also the staged changes made to the first file in the previous step have been undone!
The file is once again decorated in the Explorer view as conflicted!

Only now can the developer actually get through the full resolution process. The conflict resolution done in Part 3, step 3 will of course have to be done over again.

All in all, a mess.

Report message to a moderator