Re: What are branches?

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 20, 2009, 20:58 UTC
Message-ID: <7viqkzdoua.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20090420184048.GF25059@dpotapov.dyndns.org>

Dmitry Potapov <dpotapov@gmail.com> writes:

Show 7 quoted lines

> On Mon, Apr 20, 2009 at 03:52:59PM +0200, Michael J Gruber wrote:
> ...
>> A git branch is a pointer to a commit. That commit and its predecessors
>> are contained in the branch. A commit may be contained in multiple
>> branches, on equal footing: there is no "prime branch".
>
> This is not accurate description.

On the contrary, Michael's description is very accurate; its problem may be that it is too accurate to be useful for people who do not use certain features.

Show 5 quoted lines

> The aforementioned pointer is called
> "branch head". Branch (in strictly sense) is a line of development,
> which is defined by its head. A usual commit has one parent; a merge
> commit can have more than one parent, the first parent defines the
> branch line while other parents point to branches merged to it.

Now, that again is technically accurate but is not very useful or even harmful if you read too much into --first-parent.

Dscho may have been working on this nifty feature while my tree added tons of changes that conflict with his work based on an older tree of mine. And then he says "I have a clean history of this new feature; please pull".

         o---o---o---o---o Dscho's changes
        /
    ---o---D---D---D---o My tree
       ^     
       |       D = changes from Dmitry that conflicts with Dscho's branch
    v1.6.2

I may pull, and see a lot of conflicts; being unfamiliar with what he did, I may say "I tried to pull, and I give up---there are too many conflicts with what patches from Dmitry did recently since your tree forked, and I do not know the area affected very well, so I feel uneasy doing the merge myself."

         o---o---o---o---o Dscho's changes
        /                 .
    ---o---D---D---D---o...X My tree, unable to resolve conflicts
       ^     
       |       D = changes from Dmitry that conflicts with Dscho's branch
    v1.6.2

Dscho can do two things. One is to rebase, but his code was in use outside of my tree for some time and doing so will screw up other people.

But he can merge my tree and resolve the conflicts, and then tell me to pull again.

           Dscho's changes
         o---o---o---o---o---M
        /                   /    
    ---o---D---D---D---o---. My tree
       ^     
       |       D = changes from Dmitry that conflicts with Dscho's branch
    v1.6.2     M = merge made by Dscho for me

Now, if I did the merge, the first parent of X would have been the tip of my tree that had patches from you, and it would have merged Dscho's changes as a side branch. But if Dscho did a merge _for me_, then his merge M will have his history as the first parent, and your patches (together with possibly ones from other people) will be merged into the history as a side branch.

However, especially after I fast-forward my branch tip to M and continue building on it, it is more useful to treat Dscho's topic as the side branch that was merged to my mainline that had your patches, for the purpose of most people. Your "first parent" rule does not match that expectation.

If we made it easy for Dscho to create the merge M to record my tree as the first parent, you _could_ make the "first parent" rule to be more meaningful than it currently is, but without it, it still is merely one of the heuristics as people suggested in this discussion.