Re: Comments on recursive merge..

From: Junio C Hamano <junkio@cox.net>
Date: Nov 9, 2005, 22:56 UTC
Message-ID: <7virv1a0ro.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0511091348530.4627@g5.osdl.org>

Linus Torvalds <torvalds@osdl.org> writes:

Show 17 quoted lines

>> 
>>                  H
>>                 / \
>>            G   A   \
>>            |\ /     \ 
>>            | B       \
>>            |  \       \
>>             \  C       F
>>              \  \     / 
>>               \  D   /   
>>                \ |  /
>>                 \| /
>> 		   E
>> 
> 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.

But the point of well-poisoning you did in merge-base was to detect that E is an ancestor of B and exclude it in the first place. If it matters what F does, it means checking ancestry among B C D E and declare that B is a better ancestor than C, D, E does not help or is sometimes harmful. No question that B is always superiour ancestor than C and D, but arguably the presence of F _might_ change situation for B vs E.

I however do not see merge-base trying to take that into account and treat E differently from C and D in any way. Only because F and E had newer timestamp than C and D, we ended up finding E first and did not poison E through B, and that's why you got both B and E. I think it was just an accident. If F were older than B, I suspect the result would have been very different.

> 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.

I agree. The above example was to answer my own question in this message:

	http://marc.theaimsgroup.com/?l=git&m=112382448222823

Show 5 quoted lines

> ... 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.

I agree we should try to stay away from "heuristic" and make things safer, but after seeing the above, I'd need a bit more time to convince myself that what 'git-merge-base --all' does is *the* safe approach. Right now, it looks to me that both are heuristic that work most of the time (merge-base --all 99.99999% of the time, show-branch 99% of the time, or something like that).