I'm trying to do a complicated merge in a complicated hg repository. I'm not happy with the "newest shared ancestor" that Mercurial chooses to use as the "base" to perform the merge.
I'd like to specify a specific commit of my own choice to use as base.
Is this possible, and if so, how?
Mercurial 3.0: You can now select the ancestor to use as a merge base. You do that by setting merge.preferancestor. Mercurial will tell you about it when this makes sense. With the example below, you would see:
$ hg merge
note: using eb49ad46fd72 as ancestor of 333411d2f751 and 7d1f71140c74
alternatively, use --config merge.preferancestor=fdf4b78f5292
merging x
0 files updated, 1 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
Mercurial before version 3.0: Lazy Badger is correct that you cannot pick the ancestor picked by Mercurial when using it from the command line. However, you can do it internally and it's not too difficult to write an extension for this:
from mercurial import extensions, commands, scmutil
from mercurial import merge as mergemod
saved_ancestor = None
def update(orig, repo, node, branchmerge, force, partial, ancestor=None):
if saved_ancestor:
ancestor = scmutil.revsingle(repo, saved_ancestor).node()
return orig(repo, node, branchmerge, force, partial, ancestor)
def merge(orig, ui, repo, node=None, **opts):
global saved_ancestor
saved_ancestor = opts.get('ancestor')
return orig(ui, repo, node, **opts)
def extsetup(ui):
extensions.wrapfunction(mergemod, 'update', update)
entry = extensions.wrapcommand(commands.table, 'merge', merge)
entry[1].append(('', 'ancestor', '', 'override ancestor', 'REV'))
Put this in a file and load the extension. You can now use
hg merge --ancestor X
to override the normal ancestor. As you've found out, this does make a difference if there are several possible ancestors. That situation arises if you have criss-cross merges. You can create such a case with these commands:
hg init; echo a > x; hg commit -A -m a x
hg update 0; echo b >> x; hg commit -m b
hg update 0; echo c >> x; hg commit -m c
hg update 1; hg merge --tool internal:local 2; echo c >> x; hg commit -m bc
hg update 2; hg merge --tool internal:local 1; echo b >> x; hg commit -m cb
The graph looks like this:
@ changeset: 4:333411d2f751
|\
+---o changeset: 3:7d1f71140c74
| |/
| o changeset: 2:fdf4b78f5292
| |
o | changeset: 1:eb49ad46fd72
|/
o changeset: 0:e72ddea4d238
If you merge normally you get changeset eb49ad46fd72 as the ancestor and the file x contains:
a
c
b
c
If you instead use hg merge --ancestor 2 you get a different result:
a
b
c
b
In both cases, my KDiff3 were able to handle the merge automatically without reporting any conflicts. If I use the "recursive" merge strategy and pick e72ddea4d238 as the ancestor, then I'm presented with a sensible conflict. Git uses the recursive merge strategy by default.
Base is just used as another input to your merge tool. If you disable premerge in your Merge Tool Configuration (premerge makes the "obvious choices" for you when there are no conflicts) and invoke your merge tool manually providing copies of the 3 revisions you want as local, remote, and base, you can get whatever you want in your merge tool. Only the left parent and right parent are actually recorded in the merge.
You can't do it. Because newest shared ancestor IS real base for your merge
If you want to perform merge and don't want re-think (because your logic-base show /me/ wrong assumptions and solution-path) you can go clone-rebase-merge-export-import patch route
