Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p><strong>Mercurial 3.0:</strong> You can now select the ancestor to use as a merge base. You do that by setting <code>merge.preferancestor</code>. Mercurial will tell you about it when this makes sense. With the example below, you would see:</p> <pre><code>$ 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) </code></pre> <hr> <p><strong>Mercurial before version 3.0:</strong> 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:</p> <pre class="lang-py prettyprint-override"><code>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')) </code></pre> <p>Put this in a file and load the extension. You can now use</p> <pre><code>hg merge --ancestor X </code></pre> <p>to override the normal ancestor. As you've found out, this <strong>does</strong> 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:</p> <pre><code>hg init; echo a &gt; x; hg commit -A -m a x hg update 0; echo b &gt;&gt; x; hg commit -m b hg update 0; echo c &gt;&gt; x; hg commit -m c hg update 1; hg merge --tool internal:local 2; echo c &gt;&gt; x; hg commit -m bc hg update 2; hg merge --tool internal:local 1; echo b &gt;&gt; x; hg commit -m cb </code></pre> <p>The graph looks like this:</p> <pre><code>@ changeset: 4:333411d2f751 |\ +---o changeset: 3:7d1f71140c74 | |/ | o changeset: 2:fdf4b78f5292 | | o | changeset: 1:eb49ad46fd72 |/ o changeset: 0:e72ddea4d238 </code></pre> <p>If you merge normally you get changeset <code>eb49ad46fd72</code> as the ancestor and the file <code>x</code> contains:</p> <pre><code>a c b c </code></pre> <p>If you instead use <code>hg merge --ancestor 2</code> you get a different result:</p> <pre><code>a b c b </code></pre> <p>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 <code>e72ddea4d238</code> as the ancestor, then I'm presented with a sensible conflict. Git uses the recursive merge strategy by default.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload