4

有时当我这样做hg merge然后结帐时hg status，什么都没有打印。其他时候，我会看到另一个分支的实际变化。为什么会这样？你能解释一下合并之间的区别吗？

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

if not ctx.files():
    return ALLOW_COMMIT

但是，我遇到过提交很琐碎的情况（即，Mercurial 完成了所有工作，我不需要解决任何冲突）但ctx.files()列表不为空。然而，大多数时候，它工作正常。我本来想为每种情况发布一个示例，但我似乎无法理解这两种情况之间的区别。

基本上我在问：我怎么知道 Mercurial 合并什么时候是微不足道的？

4

3 回答 3

1

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

它确实有一些错误......但如果它显示一个空的合并差异，它肯定意味着合并是“微不足道的”（尽管有一些微不足道的合并会显示差异）。

或者，这个问题/答案可能会有所帮助：如何检查 Mercurial 中潜在的合并/变基冲突？

于 2013-02-18T20:39:29.370 回答
1

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

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

更新

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

然而，虽然这原则上应该有效，但恕我直言，这是一种过度设计。

于 2013-04-20T22:32:55.330 回答
0

Why is that happening? Can you explain the differences between the merges?

  • If it was manual merge, merger can prefer only own changes and discard changes from merged branch, i.e have dummy merge (it can be also non-interactive merge with tool=internal:local)
  • Rare case - in both files changes (from common parent) may be identical, merge-target will not be changed in this case

PS: I don't know, what is ctx.files() in hook, but if it's "files, changed in changeset", disabling commit in case of existing such files is Bad Idea (tm) - files may be modified due to clean (no conflicts) merge and in this situation Martin's idea of replying merge and checking resolve-list seems as rather good approach

于 2013-04-21T01:47:58.650 回答