Re: Newbie: report of first experience with git-rebase.

Björn Steinbrink [off-list ref] writes:

On 2007.10.31 22:39:06 +0300, Sergei Organov wrote:

quoted

Hello,

I've made my first attempt at tracking my changes to upstream git
repository using git-fetch/git-rebase workflow. I did three commits to
my master branch, and then upstream incorporated two of them in slightly
modified form, so that some conflicts are to be expected. I did
git-fetch followed by git-rebase, and finally have got the end result I
hoped for, but there were some confusion along the way. I think I'd post
the log of the session here along with my thoughts so that an interested
person could see how it works for a newbie (my thoughts and non-git
actions at the time of rebasing are marked with 'me>' prefix):

$ git fetch
[...]
$ git rebase origin
First, rewinding head to replay your work on top of it...
HEAD is now at 9c51414... Merge branch 'maint' into HEAD

Applying Fix a typo.

Wrote tree f5b2feefc021486eae9d2d84c69e0d6ead027a9d
Committed: 983e907b1360c17c7ac925d6035d82cc7243f406

Applying Use new syntax (-m option) for git-merge.

error: patch failed: Documentation/core-tutorial.txt:878
error: Documentation/core-tutorial.txt: patch does not apply
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merged Documentation/core-tutorial.txt
CONFLICT (content): Merge conflict in Documentation/core-tutorial.txt
Failed to merge in the changes.
Patch failed at 0002.

When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".

me> Nice, this conflict is expected.
me> Editing Documentation/core-tutorial.txt to resolve the
me> conflict... Conflict is resolved so that the working file matches
me> upstream version.

$ git rebase --continue
You must edit all merge conflicts and then
mark them as resolved using git add

me> Nice helpful message, -- need to do git-add

$ git add Documentation/core-tutorial.txt
$ git rebase --continue

Applying Use new syntax (-m option) for git-merge.

No changes - did you forget to use 'git add'?

When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".

me> What?! I just did the git-add! Moreover, before I did git-add, the
me> error was different and helpful. Something went wrong? 
me> Well, it's unlikely, but maybe I made a mistake of not specifying
me> the 'origin'?

$ git rebase --continue origin

Applying Use new syntax (-m option) for git-merge.

No changes - did you forget to use 'git add'?

When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".

me> No luck :( A few seconds of thinking... Hmm... no-op patch, do I
me> need to skip it? Let's try the --skip:

$ git rebase --skip

Applying Fix SYNOPSIS.

error: patch failed: Documentation/git-merge.txt:10
error: Documentation/git-merge.txt: patch does not apply
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merged Documentation/git-merge.txt
CONFLICT (content): Merge conflict in Documentation/git-merge.txt
Failed to merge in the changes.
Patch failed at 0003.

When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".

me> Aha, that's it! But why git didn't just skip the no-op patch

It wasn't a no-op patch. It had conflicts which you resolved to the
upstream version and _then_ you had a no-op.

Yes, and that's the problem. Why 'git --continue' didn't just skip this
patch that *already became no-op* after conflict resolution and forced
me to explicitly use 'git --skip' instead?

This forces one to use 'git --skip' if the patch happens to become a
no-op after conflict resolution, and 'git --continue' otherwise. Why
this complication?

-- 
Sergei.