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

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 5, 2010, 00:49 UTC
Message-ID: <7vk4trlhim.fsf@alter.siamese.dyndns.org>
In-Reply-To: <7vmxynydac.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 31 quoted lines

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