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