Newbie: report of first experience with git-rebase.

> 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

> me> automatically? Well, anyway , now I have a new expected conflict,
> me> and I'm sure I just want to skip this patch, so let's try exactly
> me> that:
> 
> $ git rebase --skip
> Dirty index: cannot apply patches (dirty: Documentation/git-merge.txt)
> 
> me> No luck :( Well, let's go the long way, -- edit conflicting
> me> Documentation/git-merge.txt (so that it matches upstream),
> 
> $ git add Documentation/git-merge.txt
> $ git rebase --skip
> Nothing to do.
> 
> me> Well, I already knew this will work, but why should I edit the file
> me> and then git-add it just to skip the patch? Is there better way?
> me> Anyway, the "Nothing to do." above is slightly confusing, -- did it
> me> actually skip the patch? So let's check the result:

> On 2007.10.31 22:39:06 +0300, Sergei Organov wrote:
>> 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.

> Hi,
> 
> On Wed, 31 Oct 2007, Sergei Organov wrote:
> 
> > 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?
> 
> Isn't that obvious?  To prevent you from accidentally losing a commit.

> J. Bruce Fields wrote:
> > I ran into the same confusion as the original poster when starting to
> > use rebase, so I suspect it's common.
> >   
> 
> I've been using rebase just about every day for close to a year and it *still*
> annoys me when it happens. Especially the "Did you forget to git add?" part of
> the message. The thought that always goes through my head is, "No, Mr. Rebase,
> I did NOT forget to git add. I remembered to git add, then you were too stupid
> to do the right thing after that."
> 
> Just happened to me this morning, in fact: I had a quick hack in place to work
> around a bug, the bug got fixed for real, and I rebased. In the process of
> conflict resolution I saw that my workaround wasn't needed any more and
> accepted the upstream version of that particular part of the file. Ran git-add
> on it, then rebase --continue, and boom, was accused of forgetting to run
> git-add.
> 
> It is a minor annoyance and nowadays I just sigh a bit and run --skip instead,
> but it'd be nice if it didn't happen. I don't like having to care whether or
> not I happened to change other files in a particular commit after I resolve
> conflicts in one file in favor of the upstream version.

> I've been using rebase just about every day for close to a year and it 
> *still* annoys me when it happens. Especially the "Did you forget to git 
> add?" part of the message. The thought that always goes through my head is, 
> "No, Mr. Rebase, I did NOT forget to git add. I remembered to git add, then 
> you were too stupid to do the right thing after that."
>
> Just happened to me this morning, in fact: I had a quick hack in place to 
> work around a bug, the bug got fixed for real, and I rebased. In the 
> process of conflict resolution I saw that my workaround wasn't needed any 
> more and accepted the upstream version of that particular part of the file. 
> Ran git-add on it, then rebase --continue, and boom, was accused of 
> forgetting to run git-add.
>
> It is a minor annoyance and nowadays I just sigh a bit and run --skip 
> instead, but it'd be nice if it didn't happen. I don't like having to care 
> whether or not I happened to change other files in a particular commit 
> after I resolve conflicts in one file in favor of the upstream version.

> On Wed, 31 Oct 2007, Sergei Organov wrote:
>
>> 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?
>
> Isn't that obvious?  To prevent you from accidentally losing a commit.

> A rebase conflict resolution that results in emptiness is a rather
> rare event (especially because rebase drops upfront the identical
> changes from the set of commits to be replayed), but it does happen.
> One could argue that "rebase --continue" can notice that the resolved
> index is identical to the tree of the HEAD commit and skip it
> automatically.
>
> Given an index that is identical to HEAD, however, it is not
> easy to safely determine if that is because the patch did not
> apply at all,

> A rebase conflict resolution that results in emptiness is a
> rather rare event (especially because rebase drops upfront the
> identical changes from the set of commits to be replayed), but
> it does happen.  One could argue that "rebase --continue" can
> notice that the resolved index is identical to the tree of the
> HEAD commit and skip it automatically.
> 
> Given an index that is identical to HEAD, however, it is not
> easy to safely determine if that is because the patch did not
> apply at all, or the patch was applied with conflicts _and_ the
> user decided to make the patch a no-op by resolving.  The
> automatic droppage of the commit needs to happen only on the
> latter and never on the former.

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> On Wed, 31 Oct 2007, Sergei Organov wrote:
>>
>>> 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?
>>
>> Isn't that obvious?  To prevent you from accidentally losing a commit.
>
> In case it is not obvious...
>
> A rebase conflict resolution that results in emptiness is a
> rather rare event (especially because rebase drops upfront the
> identical changes from the set of commits to be replayed), but
> it does happen.

> Junio C Hamano <gitster@pobox.com> writes:
> 
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> >> On Wed, 31 Oct 2007, Sergei Organov wrote:
> >>
> >>> 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?
> >>
> >> Isn't that obvious?  To prevent you from accidentally losing a commit.
> >
> > In case it is not obvious...
> >
> > A rebase conflict resolution that results in emptiness is a
> > rather rare event (especially because rebase drops upfront the
> > identical changes from the set of commits to be replayed), but
> > it does happen.
> 
> Funny how 2 of my first 3 commits suffer from this "rather rare event",
> and it was not Friday, 13 ;)

> Hi,
> 
> On Thu, 1 Nov 2007, Sergei Organov wrote:
> 
> > Junio C Hamano <gitster@pobox.com> writes:
> > 
> > > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > >
> > >> On Wed, 31 Oct 2007, Sergei Organov wrote:
> > >>
> > >>> 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?
> > >>
> > >> Isn't that obvious?  To prevent you from accidentally losing a commit.
> > >
> > > In case it is not obvious...
> > >
> > > A rebase conflict resolution that results in emptiness is a
> > > rather rare event (especially because rebase drops upfront the
> > > identical changes from the set of commits to be replayed), but
> > > it does happen.
> > 
> > Funny how 2 of my first 3 commits suffer from this "rather rare event",
> > and it was not Friday, 13 ;)
> 
> They are rare events.  In your case I guess that subtly different versions 
> were _actually_ applied (such as white space fixes),

> On Thu, Nov 01, 2007 at 02:24:37PM +0000, Johannes Schindelin wrote:
>> 
>> They are rare events.  In your case I guess that subtly different versions 
>> were _actually_ applied (such as white space fixes),
>
> That's actually pretty common, in my experience.
>
>> which is why such a rare event hit you.
>
> I'm using git to track some changes I submitted to a project that's
> mainly text, and that I only get release tarballs of.  On my most recent
> rebase all my patches got applied, but the text also got re-wrapped and
> re-indented at the same time.  So all but I think one or two of a dozen
> patches ended up with a conflict resolution and then --skip.
>
> Which may not be a case git's really intended for--fair enough.  But
> I've found it's pretty common in my kernel work too.  Either I'm
> rebasing against changes I made myself, or else a maintainer took my
> changes but fixed up some minor style problems along the way.

> "J. Bruce Fields" <bfields@fieldses.org> writes:
> 
>> On Thu, Nov 01, 2007 at 02:24:37PM +0000, Johannes Schindelin wrote:
>>> They are rare events.  In your case I guess that subtly different versions 
>>> were _actually_ applied (such as white space fixes),
>> That's actually pretty common, in my experience.
>>
>>> which is why such a rare event hit you.
>> I'm using git to track some changes I submitted to a project that's
>> mainly text, and that I only get release tarballs of.  On my most recent
>> rebase all my patches got applied, but the text also got re-wrapped and
>> re-indented at the same time.  So all but I think one or two of a dozen
>> patches ended up with a conflict resolution and then --skip.
>>
>> Which may not be a case git's really intended for--fair enough.  But
>> I've found it's pretty common in my kernel work too.  Either I'm
>> rebasing against changes I made myself, or else a maintainer took my
>> changes but fixed up some minor style problems along the way.
> 
> Ok, so I retract that "rare" comment.
> 
> Now, we have established that this is a real problem worth
> solving, what's next?

> Junio C Hamano wrote:
>>
>> Now, we have established that this is a real problem worth
>> solving, what's next?
>
> Make "git rebase --skip" skip patches regardless of tree and index state,
> but still refuse to *start* with dirty tree or index. That way, there's
> no risk of losing anything that can't be re-created unless the user asks
> for it.

> On Wed, 31 Oct 2007, Sergei Organov wrote:
>
>> 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?
>
> Isn't that obvious?  To prevent you from accidentally losing a commit.

> $ 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? 

> 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
> me> automatically? Well, anyway , now I have a new expected conflict,

> me> and I'm sure I just want to skip this patch, so let's try exactly
> me> that:
> 
> $ git rebase --skip
> Dirty index: cannot apply patches (dirty: Documentation/git-merge.txt)

> me> No luck :( Well, let's go the long way, -- edit conflicting
> me> Documentation/git-merge.txt (so that it matches upstream),
> 
> $ git add Documentation/git-merge.txt
> $ git rebase --skip
> Nothing to do.
> 
> me> Well, I already knew this will work, but why should I edit the file
> me> and then git-add it just to skip the patch? Is there better way?
> me> Anyway, the "Nothing to do." above is slightly confusing, -- did it
> me> actually skip the patch? So let's check the result:

> Junio C Hamano wrote:
>> Andreas Ericsson <ae@op5.se> writes:
>>  
>>> Make "git rebase --skip" skip patches regardless of tree and index 
>>> state,
>>> but still refuse to *start* with dirty tree or index. That way, there's
>>> no risk of losing anything that can't be re-created unless the user asks
>>> for it.
>>>     
>>
>> Sounds like a plan.
>>   
> 
> I'm unclear how that helps the usability issue here at all, though it 
> doesn't sound like an unreasonable change on its own merit.
>