Mercurial合并产生标记为已修改但二进制相等的文件

Question

我正在进行合并，我已准备好在此时提交，但我在TortoiseHg中的提交对话框显示了许多已修改的文件，但当我向父母传达时它表示所有文件二进制相等。

• 我没有，也从未启用过eol extension。
• 什么都没有更改，文件仍然注册为已修改。
• hg父母显示该文件的两个父母。

• hg stat将文件显示为已修改，例如

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

• hg diff --git没有显示任何内容，例如

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

我已经在两个不同的克隆机器上的两台不同的机器上尝试了这个，我也看到了同样的事情。

关于我如何诊断或解决此问题的其他任何想法？ 显然有些事情发生了变化，但如果它没有显示在hg diff --git中，我该如何确定它可能是什么？

更新2014/12/10：

我已经对两个父修订版的历史做了更多检查，我想我明白为什么它会变得困惑。

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

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

那么问题就变成了：

有没有办法回溯修复被视为添加和删除长时间提交的变更集的移动（新提交可以，但我无法编辑历史记录），或者我只是需要让它通过合并？

Answer 1

  

有没有办法回溯修复被视为长期提交的变更集的添加和删除的移动（新的提交可以，但我无法编辑历史记录）

好吧......好吧。更新到最近的橙色提交，其中文件具有旧名称（如果您不确定它何时发生，可以使用hg bisect查找），对新文件执行hg rename命名，提交，然后将其合并到当前的Orange头中。 Mercurial 应该足够聪明，可以将文件注册为正确重命名，并且不会引起冲突（我们知道这是因为更复杂的Apple / Orange合并没有）。

  

或者我只需要在合并中让它通过？

这更容易。 Mercurial的合并算法非常智能。它可以处理这样的情况。

除非您有第三个分支，其中文件从未移动过，否则第二个选项不太可能导致问题。如果你确实有这样的分支，只要你将它合并到Apple重命名的后代（或者从这样的后代合并），你应该没问题。主要的困难是与Orange分支的合并。