Mercurial merge会生成标记为modified但二进制相等的文件

我正在进行合并，现在我已经准备好提交了，但是我在TortoiseHg中的提交对话框显示了许多已修改的文件，但是当我向父级提交时，它显示所有文件都是二进制相等的

• 我没有，也从来没有启用过
• “还原”不更改任何内容，文件仍注册为“已修改”
• hg parents显示文件的两个父级
• hg stat将文件显示为已修改，例如

  c:\Projects\MyProject>hg stat Authorization\AuthorityGroups.cs  
  M Authorization\AuthorityGroups.cs  
  

• 没有显示任何内容，例如

  c:\Projects\MyProject>hg diff --git Authorization\AuthorityGroups.cs   
  c:\Projects\MyProject>   
  

我在两台不同的机器上，在两个不同的克隆机上试过，我看到了同样的情况

关于如何诊断或修复此问题，还有其他想法吗？ 很明显，有些东西已经改变了，但是如果它没有在hg diff--git中显示出来，我如何确定它可能是什么呢

2014/12/10更新：

我对两个父版本的历史做了更多的检查，我想我明白了为什么它会变得混乱

• 默认情况下，我们在修订版1中添加了原始父文件
• 在Apple分支上，该文件已重命名，以将其移动到新位置
• 在橙色分支上，已添加文件以将其移动到相同的新位置

因此，两个分支上的文件都是二进制的，并且位于相同的位置，但Mercurial可能会将其标记为要合并的差异，因为它们是通过明显不同的方式到达的

于是问题就变成了：

是否有任何方法可以回顾性地修复在长提交的变更集上被视为添加和删除的移动（新提交可以，但我无法编辑历史记录），还是只需要在合并中让它通过

是否有任何方法可以回顾性地修复在长提交变更集上被视为添加和删除的移动（新提交可以，但我无法编辑历史记录）

嗯。。。某种程度上。更新到最新的橙色提交，其中文件有其旧名称（如果不确定具体发生时间，可以使用

hg bisect

查找），对新名称执行

hg rename

，提交，然后将其合并到当前的橙色头中。Mercurial应该足够聪明，可以将文件注册为正确重命名的文件，并且不会导致冲突（我们知道这一点，因为更复杂的Apple/Orange合并没有）

还是我只需要让它在合并中通过

这比较容易。Mercurial的合并算法非常聪明。它可以很好地处理这种情况

---

除非您有第三个从未移动过文件的分支，否则第二个选项不太可能导致问题。如果您确实有这样一个分支，那么只要您将其合并到Apple rename的子代（或从这样的子代合并），就应该没有问题。主要的困难在于与Orange分支的合并。

我认为您已经这样做了，但如果没有，请分别对每个父级进行差异，因为它可能是二进制的，与第一个父级相等，但与第二个不同。（只需右键单击第二个父项并执行“diff to local”。）不幸的是，它肯定报告的二进制数等于两个父项，但我刚刚对其中一个示例中的每个父项执行了单独的diff，正如您所建议的，两个示例都没有返回任何结果，因此，就hg diff--git而言，这些文件看起来确实是相同的。您可以发布来自hg stat的结果吗？c:\Projects\MyProject>hg stat Authorization\AuthorityGroups.cs M Authorization\AuthorityGroups.cst这是一种可能的策略。我最终还是让合并通过了，当然一切都很好。我还有几件事要做，我可以试试看。这种策略的缺点当然是我必须手动重做重命名，而且可能会有相当多的重命名，因此懒惰最终成为决定因素！