Re: request for documentation about branch surgery

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 7, 2009, 15:52 UTC
Message-ID: <7v3a98bidr.fsf@alter.siamese.dyndns.org>
In-Reply-To: <200907071213.25418.bruno@clisp.org>

Bruno Haible <bruno@clisp.org> writes:

Show 17 quoted lines

>> If you think "git merge" _copies_, you will never understand what "merge"
>> does. ... There is no copying involved anywhere .  It only creates a new
>> commit 
>
> There are two cases of "git merge" operation: the one that creates a diamond
> commit, and the one that doesn't (the "simple" case of "git merge"). The latter
> operation I found useful in achieving this surgery:
>
>             C---D---E              topic
>            /
>       A---B                        master
>
>   =>
>
>             C---D---E              topic
>            /
>       A---B---C---D---E            master

If C, D, E on the above two lines are the _same_ commit, i.e. with the same history and same object IDs, then the picture should instead look like this:

             C---D---E topic
            /
       A---B master

   =>
                       master
             C---D---E topic
            /
       A---B master@{1}

If that is the case, you drew the picture incorrectly, and it shows the misunderstanding of your git object model and what a git branch is.

The latter I have already explained to you, but here is a hint.

    Do not think of a branch as "the upper line is topic, the lower line
    is master".  A branch is just a pointer to _a commit_.  IOW, in the
    picture I drew to correct yours, master and topic point at "E".  It
    does _not_ point at the line that C, D, and E are on.  Similarly,
    master@{1} points at the commit "B", not at the line A and B are on.

You claimed that you understand in your response, but judging from the way you wrote the above picture, I can tell that you don't understand what a branch in git is. Otherwise you would have drew it like how I did, and you wouldn't have used the word "copy".

If you instead for some reason _want_ a forked history where C, D and E are _duplicated_, then you would start from the first picture, fast forward master to "E", and would force rebase onto B, to end up with a picture like this.

             C---D---E topic
            /
       A---B---C'--D'--E' master

But there is no reason to do this.