为什么Mercurial不需要"递归合并策略"？

Question

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

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

谢谢

Answer 1

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

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

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

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

这是分支合并中最难做的事情之一，我不知道有哪个源代码控制系统能够真正正确地做到这一点。