Adding merge --ancestor option?

[Matt Mackall]

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

-- 
Mathematics is the supreme nostalgia of our time.