git - 为什么 Mercurial 不需要 "recursive merge strategy"？

Question

据我所知，git 的默认 merge 策略是“递归”的，这意味着当不止一个“共同祖先”最终成为“好的候选者”时，git 将 merge 它们并为贡献者创建一个新的“虚拟共同祖先”。它基本上有助于解决文件已经 merge 的情况，并避免再次 merge 它们或提出不正确的 merge 贡献者。

我的问题是:如果 Mercurial 不使用“递归”，它如何处理相同的情况？

谢谢

Answer 1

大多数版本控制系统不知道如何处理 merge 有多个基础版本的情况。数学 merge 方程是

Result = Destination + SumOf(I=1-N)(Base(I) - Source(I))

在大多数情况下，N=1，您会得到一个典型的 3 向 merge 工具可以处理的源、目标和基础版本的经典 merge 。尽管许多源代码控制系统甚至在这种简单的情况下都没有用于查找基本版本的正确算法。为此，您需要沿着 merge 箭头向上追溯版本树，直到您遇到共同的祖先。但有时共同祖先太远，不符合上面 N=1 的等式，在这种情况下，您需要为多个部分 merge 找到多个共同祖先。

例如，一个分支被上下 merge 多次，然后我们尝试将这个分支的更改交叉 merge 到另一个分支。在这种情况下，N > 1，但低于源分支上的向下 merge 数。

这是分支 merge 中最难做的事情之一，我不知道实际上正确执行此操作的源代码控制系统。