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

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 sprint 以来，这个话题就被卡住了。

为了减少此类问题，我建议您建立一个客户端-服务器拓扑，以便开发人员只与官方存储库合并。也许 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

对于合并集的共同祖先的错误碱基检测，已知一个弱点：

如果任何合并集包含与合并编辑无关的内容，则可能是错误的

Answer 3

我猜，祖先是 14294。由于您的两个新提交都是合并，因此您现在有多个祖先，这使得选择模棱两可。

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