如何指定要在“汞合并"中使用的合并基础 [英] How do I specify a merge-base to use in a 'hg merge'

问题描述

我正在尝试在复杂的hg存储库中进行复杂的合并.我对Mercurial选择用作执行合并的基础"的最新共享祖先"感到不满意.

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:现在，您可以选择祖先用作合并基础.您可以通过设置merge.preferancestor来实现.当有意义时，Mercurial会告诉您有关情况.在下面的示例中，您将看到:

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)

---

3.0之前的Mercurial :Lazy Badger是正确的，因为您不能从命令行使用Mercurial挑选的祖先.但是，您可以在内部进行操作，为此编写扩展不是很困难:

---

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

图形如下:

@    changeset: 4:333411d2f751
|\
+---o  changeset: 3:7d1f71140c74
| |/
| o  changeset: 2:fdf4b78f5292
| |
o |  changeset: 1:eb49ad46fd72
|/
o  changeset: 0:e72ddea4d238

如果正常合并，您将获得变更集eb49ad46fd72作为祖先，并且文件x包含:

If you merge normally you get changeset eb49ad46fd72 as the ancestor and the file x contains:

a
c
b
c

如果您改用hg merge --ancestor 2，则会得到不同的结果:

If you instead use hg merge --ancestor 2 you get a different result:

a
b
c
b

在两种情况下，我的KDiff3都能自动处理合并，而无需报告任何冲突.如果我使用递归"合并策略并选择e72ddea4d238作为祖先，那么就会遇到明智的冲突. Git默认使用递归合并策略.

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.

这篇关于如何指定要在“汞合并"中使用的合并基础的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！