有时，当我执行hg merge然后签出hg status时，不会打印任何内容。其他时候，我会看到另一个分支的实际变化。为什么会发生这种情况？你能解释一下合并之间的区别吗？
这个问题的重点是：我们将Mercurial连接到Jira，并强制每个提交都必须包含一个任务id，并且在推送之前，每个这样的提交都将经过代码审查。然而，我们不需要对"琐碎"合并进行审查，所以我们在提交挂钩中进行检查：
if not ctx.files():
return ALLOW_COMMIT
然而，我遇到过这样的情况：提交很琐碎（即Mercurial完成了所有的工作，我不需要解决任何冲突），但ctx.files()列表不是空的。然而，大多数时候，它运行良好。我本想为每种情况发布一个例子，但我似乎不明白这两种情况之间的区别。
基本上，我在问：当Mercurial合并微不足道时，我该如何判断？
您可以重播合并。如果它失败了，那就不是一件小事。如果成功，请将结果与以前提交的合并进行比较。如果两个合并结果都相同，那么这是一个微不足道的结果，否则就需要手动调整。
但是，这假设重播使用与原始合并相同的合并算法。不同的Mercurial版本和配置可能与这一假设相冲突。
更新
如果你想在提交合并之前进行这些检查，你可以使用预合并挂钩来"预览"合并（而不是事后重播）。在钩子中，自动执行建议的合并并检查冲突。没有冲突→将合并差异保存在一个临时文件中可能是微不足道的。不要忘记取消由自动合并（hg up -r . -C）引起的工作副本更改。然后，当用户想要提交她的实际合并时，使用预提交挂钩来检查手动合并是否与存储在临时文件中的自动合并不同。如果不同，则需要进行审查。
然而，尽管这在原则上应该起作用，IMHO这有点过于工程化了。
事实证明，这是一个比您预期的更困难的问题。一两年前，我试图编写一个插件来生成"合并差异"，只显示合并中引入的更改：https://www.mercurial-scm.org/wiki/MergediffExtension
它确实有一些错误……但如果它显示了一个空的合并diff，这肯定意味着合并是"琐碎的"（尽管有一些琐碎的合并会显示diff）。
或者，这个问题/答案可能会有所帮助：我如何在Mercurial中检查潜在的合并/重组冲突？
为什么会发生这种情况？你能解释一下合并之间的区别吗？
- 如果是手动合并，则合并可以只保留自己的更改并放弃合并分支中的更改，即进行虚拟合并（也可以是与
tool=internal:local的非交互式合并） - 罕见情况-在两个文件的更改（来自共同父文件）可能相同的情况下，合并目标在这种情况下不会更改
PS：我不知道，钩子中的ctx.files()是什么，但如果是"文件，在变更集中更改"，在现有此类文件的情况下禁用提交是坏主意（tm）-文件可能会因为干净（无冲突）的合并而被修改，在这种情况下，Martin回复合并并检查解决列表的想法似乎是一种很好的方法