我如何判断Mercurial合并何时微不足道？

有时，当我执行

hg merge

并签出

hg status

时，不会打印任何内容。其他时候，我看到其他分支的实际更改。为什么会这样？你能解释一下合并之间的区别吗

这个问题的要点是：我们将Mercurial连接到Jira，并强制要求每个提交必须包含一个任务id，并且在推送之前对每个这样的提交进行代码审查。但是，我们不需要对“琐碎的”合并进行审查，因此我们在提交挂钩中执行以下检查：

if not ctx.files():
    return ALLOW_COMMIT

但是，我遇到过这样的情况：提交很简单（即Mercurial完成了所有工作，我不需要解决任何冲突），但是

ctx.files（）

列表不是空的。然而，大多数时候，它工作得很好。我本想为每种情况都贴一个例子，但我似乎无法理解这两种情况之间的区别

---

基本上，我是在问：我如何判断Mercurial合并何时是微不足道的呢？

事实证明，这是一个比您预期的更困难的问题。一两年前，我尝试编写一个插件来生成“合并差异”，只显示合并中引入的更改：

它确实有一些bug…但是如果它显示一个空的merge diff，它肯定意味着合并是“平凡的”（尽管有一些平凡的合并它会显示一个diff）

---

或者，此问题/答案可能会有所帮助：

您可以重播合并。如果失败了，那就不是一件小事。 如果成功，请将结果与以前提交的合并进行比较。如果两个合并结果都相同，那么这是一个微不足道的结果，否则会进行手动调整

但是，这假设重播使用与原始合并相同的合并算法。不同的Mercurial版本和配置可能与此假设相冲突

更新 如果您想在提交合并之前执行这些检查，您可以使用预合并挂钩“预览”合并（而不是事后重播）。在钩子中，自动执行建议的合并并检查冲突。没有冲突→ 将合并差异保存在临时文件中可能很简单。不要忘记放弃由自动合并引起的工作副本更改（

hg up-r.-C

）。然后，当用户想要提交其实际合并时，使用预提交钩子检查手动合并是否与临时文件中存储的自动合并不同。如果不同，则需要进行审查

然而，虽然这在原则上应该是可行的，但这有点过于工程化了

为什么会这样？你能解释一下合并之间的区别吗

• 如果是手动合并，则合并只能选择自己的更改并放弃合并分支的更改，即进行虚拟合并（也可以是非交互式合并，使用

  tool=internal:local

  ）
• 罕见情况-在两个文件中（来自公共父级）的更改可能相同，在这种情况下合并目标不会更改

---

PS：我不知道hook中的

ctx.files（）

是什么，但如果是“文件，在变更集中更改”，在现有此类文件的情况下禁用提交是一个坏主意（tm）-文件可能会因清理而被修改（无冲突）合并，在这种情况下，回复合并并检查解决列表似乎是一种不错的方法

从技术上讲，如何“重放”合并？@AmirRachum:replay a merge:get the parent nodes of a merge，然后更新到第一个父级并发出一个

hg merge-r

。在提交钩子中进行合并不是很危险吗？事实上，这不是提交钩子的选项。预推钩可能是更好的选择。这不是你真正想要做的吗？在推之前做一些检查？我可以在钩子推的时候做，但是我更愿意在仍然需要回滚的时候做。