merge - Mercurial merge 会生成标记为已修改但二进制相等的文件

Question

我正在进行 merge ，此时我已准备好提交，但我在 TortoiseHg 中的提交对话框显示许多文件已修改，但是当我与 parent 进行比较时，它说所有文件都是二进制相等的。

我没有也从未有过 eol extension启用。

Revert 没有任何改变，文件仍然注册为已修改。

hg parents 显示文件的两个父级。

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 分支上，该文件已被重命名以将其移动到新位置。

在橙色分支上，已添加文件以将其移动到相同的新位置。

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

那么问题就变成了:

有什么方法可以追溯修复在长期提交的变更集上被视为添加和删除的移动(新提交可以，但我无法编辑历史记录)，或者我只需要让它通过 merge ？

Answer 1

Is there any way to retrospectively repair the move being treated as an add and delete on a long committed changeset (a new commit would be fine, but I can't edit the history)

嗯……有点。更新到最新的 Orange 提交，其中文件具有旧名称(如果您不确定它发生的确切时间，可以使用 hg bisect 找到它)，执行 hg rename到新名称，提交，然后将其 merge 到当前的 Orange head 中。 Mercurial 应该足够聪明，可以将文件注册为正确重命名，并且不会引起冲突(我们知道这一点，因为更复杂的 Apple/Orange merge 没有)。

or do I just need to let it go through in the merge?

这更容易。 Mercurial 的 merge 算法非常聪明。它可以很好地处理这样的情况。

除非您有一个从未移动过文件的第三个分支，否则第二个选项不太可能导致问题。如果您确实有这样的分支，只要将它 merge 到 Apple 重命名的后代(或从这样的后代 merge )，就可以了。主要的困难在于与 Orange 分支的 merge 。