Re: [RFC] Looking at multiple ancestors in merge

[A Large Angry SCM <gitzilla@gmail.com>]

Daniel Barkalow wrote:
> I'm starting to work on letting the merging process see multiple
> ancestors, and I think it's messy enough that I should actually discuss
> it.
> 
> Review of the issue:
> 
> It is possible to lost reverts in cases when merging two commits with
> multiple ancestors, in the following pattern: (letters representing blobs
> at some filename, children to the right)
> 
> a-b-b-a-?
>  \ X   /
>   a-b-b
> 
[Lots of stuff deleted]

There seems to be a lot of effort being put into auto-magically choosing
the "right" merge in the presence of multiple possible merge bases.
Unfortunately, most (all?) of the proposals are attempting to divine
intent, and so, are guaranteed to be 100% wrong at least some of the time.

Wouldn't it be better, instead, to detect that current merge being
attempted is ambiguous and require the user to specify the correct merge
base? The alternative is a tool that appears to work all of the time but
does the wrong thing some of the time.