mercurial - 如何判断Mercurial合并是否微不足道？

有时当我执行hg merge然后查看hg status时，不会打印任何内容。其他时候我看到其他分支的实际变化。为什么会这样？你能解释合并之间的差异吗？

这个问题的重点在于：我们将Mercurial连接到Jira并强制执行每个提交必须包含一个任务ID，并且每个提交都将在推送之前进行代码审查。但是，我们不需要对“普通”合并进行评论，因此我们在提交钩子中进行检查：

if not ctx.files():
    return ALLOW_COMMIT

但是，我遇到了提交很简单的情况（即，Mercurial完成了所有工作，我不需要解决任何冲突），但ctx.files()列表不为空。然而，大多数情况下，它工作正常。我本来希望为每个案例发布一个例子，但我似乎无法得出两种情况之间的区别。

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

这实际上是一个比你期望的更难的问题。一年或两年前，我尝试编写一个插件来生成＆＃34;合并差异＆＃34;，仅显示合并中引入的更改：https://www.mercurial-scm.org/wiki/MergediffExtension

它确实有一些错误...但如果它显示一个空的合并差异，它肯定意味着合并是＆＃34;平凡的＆＃34; （虽然有一些简单的合并，它会显示差异）。

或者，这个问题/答案可能有所帮助：How do I check for potential merge/rebase conflicts in Mercurial?

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

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

更新

如果您想在提交合并之前进行这些检查，可以使用预合并挂钩“预览”合并（而不是之后的重放）。在钩子中，自动执行建议的合并并检查冲突。没有冲突→可能是微不足道的，将合并差异保存在temprorary文件中。不要忘记了解自动合并（hg up -r . -C）导致的工作副本更改。然后，当人们想要提交她的实际合并时，使用预提交钩子来检查手动合并是否与存储在临时文件中的自动合并不同。如果不同，则需要进行审核。

然而，虽然这应该是原则上的，但恕我直言，它有点过度工程。

为什么会这样？你能解释合并之间的差异吗？

如果是手动合并，合并可以只选择自己的更改并放弃合并分支的更改，即具有虚拟合并（它也可以与tool=internal:local进行非交互式合并）
罕见的情况 - 两个文件中的更改（来自普通父级）可能相同，在这种情况下不会更改merge-target

PS ：我不知道，什么是ctx.files()挂钩，但如果它是“文件，在变更集中更改”，则在现有此类文件的情况下禁用提交是错误的想法（tm） - 文件可能因干净（无冲突）合并而被修改，在这种情况下Martin's idea回复合并和检查resolve-list似乎是一个很好的方法

如何判断Mercurial合并是否微不足道？

3 个答案:

更新