Adding merge --ancestor option?

[Angel Ezquerra Moreu]

On Thu, Mar 22, 2012 at 2:37 PM, Matt Mackall <mpm at selenic.com> wrote:
> On Wed, 2012-03-21 at 20:48 -0400, Greg Ward wrote:
>> On 21 March 2012, Matt Mackall said:
>> > > 1) Alice and Bob are working concurrently from the same changeset on
>> > >    branch 1.0
>> > > 2) Alice commits on 1.0
>> > > 3) Alice merges to 1.1
>> > > 4) Alice merges to default
>> > > 5) Bob commits on 1.0
>> > > 6) Bob merges to 1.1, gets a conflict, resolves it
>> > > 7) Bob merges to default
>> > > 8) Alice pushes and goes home: she's done her day's work
>> > > 9) Bob attempts to push and fails: "push creates remote heads"
>> > > 10) Bob pulls
>> > > 11) Bob merges with Alice on 1.0, 1.1, and trunk
>> > > 12) Bob pushes and goes home: he's done his day's work
>> > > 13) Carl starts work at the tip of branch 1.0 (Bob's merge with Alice)
>> > > 13) Carl merges 1.0 to 1.1: FAIL: he gets Bob's conflict!
>> >
>> > This is yet another case where we can't do any meaningful
>> > differentiation between possible ancestors (the commits in (2) and (5)
>> > in this case). We could perhaps walk the graph and notice that (5) has a
>> > descendant merge with a conflict, and thus score it higher, but it'll
>> > still be trivial to create scenarios with ties.
>>
>> I was confused at first by how you can detect conflict after-the-fact.
>
> Simple. A merge without conflicts will have no files listed in the
> changeset. In this scheme, we'd try to pick the merge path that had the
> most conflicts already resolved. So we'd notice that one of the choices
> of ancestor implied merge 'legs' including Bob's conflict resolution
> from (6) and choose it over the one with no resolutions in its legs.
>
> This tweak is much more work than its worth, though, as it nibbles only
> a small chunk off the ambiguous domain.
>
>> > So there are two ways we can go:
>> >
>> > - allow manual ancestor selection (restricted to heads(::x and ::y))?
>> > - invent a merge operator that's well-defined for multiple ancestors
>> >
>> > It's not too hard to see how the latter might work, if we ignore
>> > renames.
>>
>> That would indeed be nifty. I'll have to screw on the old thinking cap
>> and cogitate over this a bit.
>
> I'm starting to write up some design notes for this idea, which I'm
> calling "concensus merge".
>
> A quick measurement on the Mercurial repo shows:
>
> 1911 merges
> 83 with two or more merge ancestors
> 1 with three

Matt,

is there a simple way (e.g. revset) to repeat that measurement? I
suspect that mercurial's history is probably more linear than most,
given the patch based workflow, the excellent review process and the
high commit quality standards. The fact that there are only 2 named
branches probably contributes to that as well.

I could repeat those measurements on some of our repos to give you
another measurement point.

Cheers,

Angel