Linus Torvalds <torvalds <at> osdl.org> writes:

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

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