Re: What's cooking in git.git (Mar 2010, #01; Wed, 03)

> Junio C Hamano <gitster@pobox.com> writes:
> >     $ git branch branch2                        <2>
> >
> > I take it that this is supposed to be "checkout -b branch2".
> >
> >     $ git reset --keep start                    <3>
> >     ------------
> >
> >     <1> This commits your first edits in branch1.
> >     <2> This creates branch2, but unfortunately it contains the previous
> >     commit that you don't want in this branch.
> >     <3> This removes the unwanted previous commit, but this keeps the
> >     changes in your working tree.
> >
> > The above sequence is not very convincing.  After you edited the second
> > time, you create branch2 and that is presumably because you realized that
> > the change in the work tree belongs to a separate topic.  It would be a
> > lot more natural to do this:
> >
> >     $ git tag start ;# we do not have to tag, but just to make the
> >                        remainder of the illustration easier to read...
> >     $ git checkout -b branch1
> >     $ edit	    ;# do the work for the first topic
> >     $ git commit    ;# and commit
> >     $ edit          ;# start working more and then realize that the
> >     		       change belongs to a separate topic, and the previous
> >                        commit is unrelated to that new topic
> >     $ git checkout -b branch2 start
> >     $ edit          ;# continue working
> >     $ git commit    ;# and conclude it
> >
> > so the example makes the use of "reset --keep" look artificial.
> 
> Nah, what was I thinking.  If I rephrase your side note <2> and <3> a
> little bit, everything makes sense.  Perhaps like so:
> 
>     <2> In the ideal world, you could have realized that the earlier
>     commit did not belong to the new topic when you created and switched
>     to branch2 (i.e. "git checkout -b branch2 start"), but nobody is
>     perfect.
> 
>     <3> But you can use "reset --keep" to remove the unwanted commit after
>     you switched to "branch2".
> 
> And it becomes very clear that "reset --keep" is a sensible way to recover
> from this mistake.  No need to do "read-tree -m -u" followed by "reset"
> anymore.
> 
> Do you think I finally understood what "reset --keep" is about?