由于错误的合并基础合并问题：发生了什么？

Question

我有一个存储库，其中两个修订版（14321和14319）共享父级（14318） - 两个更改集都是直接子级 14318.但是，修订集查询ancestor(14321, 14319) 不返回14318，而是返回更旧的变更集。 发生了什么事？

TortoiseHg的屏幕截图：

背景：我最近遇到了奇怪的合并冲突，原因是由于mercurial尝试重新应用已经合并的更改。我能够将它追溯到一个奇怪的合并基础选择，导致两个头部包含相同的变化 - 但我不明白为什么会发生这种情况以及我将来如何防止它（我选择了DVCS部分避免这些问题首先......）

Answer 1

图片显示，只有两个共同的祖先。因此，它看起来像一个纵横交错的合并案例，其中合并问题来自于选择一个或另一个共同的祖先。

参考文献：

• https://bz.mercurial-scm.org/show_bug.cgi?id=1327#c18
• http://www.gelato.unsw.edu.au/archives/git/0504/2279.html
• http://wiki.vestasys.org/MergingFuture/Food4Thought/TrickyCases
• http://revctrl.org/CrissCrossMerge?action=recall&rev=11

建议使用新的合并算法（https://www.mercurial-scm.org/wiki/ConsensusMerge）。但是，自Mercurial的2.3冲刺以来，这个话题一直停滞不前。

为了减少此类问题，我建议您建立一个客户端 - 服务器拓扑，以便开发人员只与官方存储库合并。也许rebase也有帮助。

纵横交错合并是这样的：

   B --- D
  / \   / \
 /   \ /   \ 
A     X     F 
 \   / \   /
  \ /   \ /
   C --- E

在你的情况下，它是：

           B
-----------o----               } stable/production
      C     \   \       F
------o------o---\------o      } default
       \     D    \    /
        -----------o---        } feature
                   E

A = ?
B = 14318
C = 14294
D = 14319
E = 14321
F = ?

要生成F，有两种可能的电路：B-D-E-F和C-D-E-F。 Mercurial选择了后者。

如果您没有合并生产和功能分支，您可以避免纵横交错。 此修补程序可能已通过默认分支传播到功能分支。日志将是：

           B
-----------o               } stable/production
      C     \       F
------o------o------o      } default
       \    D \    /
        -------o---        } feature
               E

Answer 2

对于合并集共同祖先的错误基本检测，一个weak point是已知的：

如果任何合并集包含与合并无关的 编辑

，则可能是错误的

Answer 3

我猜，祖先是14294.由于你的两个新提交都是合并，你现在有一个以上的祖先，这使得选择模糊不清。

不幸的是，没有办法告诉mercurial哪些潜在的祖先可以使用。