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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano <gitster@xxxxxxxxx> 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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]