Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » EGit » Rebase quirk(Explicit rebase v implicit rebase via pull)
Rebase quirk [message #957856] Thu, 25 October 2012 10:50 Go to next message
R Shapiro is currently offline R Shapiro
Messages: 379
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 09:30 Go to previous messageGo to next message
R Shapiro is currently offline R Shapiro
Messages: 379
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 12:53 Go to previous messageGo to next message
R Shapiro is currently offline R Shapiro
Messages: 379
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

Re: Rebase quirk [message #965982 is a reply to message #965968] Wed, 31 October 2012 13:03 Go to previous message
R Shapiro is currently offline R Shapiro
Messages: 379
Registered: June 2011
Senior Member
File as bug

https://bugs.eclipse.org/bugs/show_bug.cgi?id=393272

after a few editing errors...

Report message to a moderator

Previous Topic:Support required in Submodules in EGIT
Next Topic:JGit working in Android; Lcom/jcraft/jsch/Channel errors?
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Sun Apr 20 15:59:53 EDT 2014

Powered by FUDForum. Page generated in 0.05311 seconds