Mercurial merge results in files labelled modified but which are binary equal

Question

I'm in the process of doing a merge, and I'm ready to commit at this point but my commit dialog in TortoiseHg is showing many files as modified but when I diff to parents it says all files are binary equal.

• I do not have and have never had the eol extension enabled.
• Revert changes nothing, the file is still registering as modified.
• hg parents shows two parents for the file.

• hg stat shows the file as modified, e.g.

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

• hg diff --git shows nothing, e.g.

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

I've tried this on two different machines on two separate clones and I'm seeing the same thing.

Any other thoughts for how I could diagnose or fix this? Clearly something has changed but if it's not showing in hg diff --git how can I establish what that might be?

Update 2014/12/10:

I've done a bit more checking on the history of the two parent revisions and I think I see why it's getting confused.

• We've got the original parent file added in revision 1 on default.
• On the Apple branch the file has been renamed to move it to a new location.
• On the Orange branch the file has been added to move it to the same new location.

So the file on both branches is binary identical and at the same location, but presumably Mercurial is flagging it as a difference to be merged because they arrived there by apparently different means.

So the question then becomes:

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) , or do I just need to let it go through in the 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)

Well... sort of. Update to the most recent Orange commit in which the files had their old names (you can use hg bisect to find it if you're not sure exactly when it happened), do hg rename to the new names, commit, and then merge this into the current Orange head. Mercurial should be smart enough to register the files as properly renamed, and it won't cause conflicts (we know this because the more complex Apple/Orange merge didn't).

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

This is easier. Mercurial's merging algorithm is quite smart. It can deal with situations like this just fine.

Unless you have a third branch in which the files were never moved, the second option is unlikely to cause a problem. If you do have such a branch, you should be fine as long as you merge it into a descendant of the Apple rename (or merge from such a descendant). The major difficulty would be with merges to or from the Orange branch.