Re: Comments on recursive merge..

From: Linus Torvalds <torvalds@osdl.org>
Date: Nov 9, 2005, 21:58 UTC
Message-ID: <Pine.LNX.4.64.0511091348530.4627@g5.osdl.org>
In-Reply-To: <7virv1efzv.fsf@assigned-by-dhcp.cox.net>

On Wed, 9 Nov 2005, Junio C Hamano wrote:

Show 22 quoted lines

> 
> The current show-branch code does the same as merge-base in the
> pathological example depicted in merge-base.c, but they seem to
> do different things to this picture (commit grows from bottom to
> top, time flows alphabetically; find base between G and H).
> 
>                  H
>                 / \
>            G   A   \
>            |\ /     \ 
>            | B       \
>            |  \       \
>             \  C       F
>              \  \     / 
>               \  D   /   
>                \ |  /
>                 \| /
> 		   E
> 
> "git-merge-base --all" says the merge bases are B and E, while
> "show-branch --merge-base" mentions only B.  In this case the
> latter is probably the better answer.

I don't agree.

Sure, B _may_ be the right answer for a particular merge strategt, but there's no way of knowing. Maybe all the big changes came in through F, and H is the merge that sorted that out, and E actually ends up being the better base.

So I think from a correctness standpoint, the only thing that matters is "git-merge-base --all", and anything that doesn't know to return both E and B looks potentially buggy.

> Actually git-merge-base without --all only mentions E.

Well, we should really consider anything that doesn't take them all into account to be a bug waiting to happen (or rather, a merge waiting for a disaster), but E is the right one, since it's the more recent one).

Now, this case obviously depends on history being almost maximally insane (ie pretty much _all_ the dates are wrong). So in practice we probably don't care.

So maybe "git-show-branch --merge-base" ends up acceptable as a faster way to do the quick "let's see if we can find _some_ merge-base to do the in-index merge with", but personally I'd much rather always do a "git-merge-base --all", and only do the fast index merge if we only have one potential parent.

That way there would never any question about what the "quick merge" does.

			Linus