我们最近改用 Mercurial。一切都进行得很顺利，直到我们有两次提交的更改丢失的事件。检查日志并没有让我们变得更聪明。
下面是一个例子。在 (1) 提交的文件恢复到在 (2) 的先前状态，即使合并中没有提及这些文件。
我可以检查什么来了解文件恢复的原因？
【问题讨论】：
hg pull 之后使用hg rebase 以使图形更平坦，更少分支。
标签： mercurial mercurial-commit
此图中有 三个 有趣的变更集可以影响 (2) 合并：
Mercurial 进行合并时，仅有三个重要的变更集：您合并的两个头及其共同祖先。在三路合并中，现在的逻辑是：
ancestor parent1 parent2 => merge
X X Y Y (clean)
X Y X Y (clean)
X Y Y Y (clean)
X Y Z W (conflict)
这样读取表格：“如果祖先是X，第一个父项也是X，第二个父项是Y，那么合并将包含Y”。换句话说：三路合并有利于改变，并且会让修改获胜。
你可以找到祖先
$ hg log -r "ancestor(p1(changeset-2), p2(changeset-2))"
changeset-2 是上面标有 (2) 的那个。当你说
在 (1) 提交的文件恢复到在 (2) 的先前状态，即使在合并中未提及这些文件。
那么重要的是要理解“合并”只是显示如何混合其他两个变更集的快照。 “在”合并中所做的更改是此快照与其 两个 父更改集之间的差异：
$ hg status --rev "p1(changeset-2):changeset-2"
$ hg status --rev "p2(changeset-2):changeset-2"
这显示了合并变更集分别与其第一个和第二个父项有何不同。我确信这些文件在其中一个列表中被提及——除非合并毕竟不是罪魁祸首。
当您检查三个变更集以及它们之间的差异时，您可能会发现有人必须解决冲突（上面合并表中的第四行）并在某个步骤中选择了错误的文件。
【讨论】：
2 处的合并介于一个非常旧的分支（深蓝色，在提交 1 之后从主线/绿色分支分叉）和一个更旧的分支（浅蓝色，自提交 1 之前就没有与主线同步)
似乎 2 处的合并选择了错误的文件版本 - 从这里无法判断是工具选择了错误的文件版本，还是用户手动选择了错误的版本。
编辑添加：
为了帮助准确追踪 2 时发生的变化，您可以使用 hg diff -r REV1 -r REV2，它会显示任何两个修订版之间的逐行差异。
当您知道在第 1 点和第 2 点之间的某个时间引入了错误时，hg bisect 可能会帮助您找到错误的确切来源：
hg bisect [-gbsr] [-U] [-c CMD] [REV]
变更集的细分搜索
This command helps to find changesets which introduce problems. To use,将您知道的最早的变更集标记为错误，然后标记 没有问题的最新变更集。
Bisect 会将您的工作目录更新为用于测试的修订版 （除非指定了 -U/--noupdate 选项）。一旦你有 执行测试，将工作目录标记为好或坏，然后平分 将更新到另一个候选变更集或宣布它 找到了错误的修订版。
【讨论】：