Mercury merge results in files marked as modified but equivalent to binary

Question

I am performing a merge and I'm ready to commit at this point, but my commit dialog in TortoiseHg shows a lot of files as modified, but when I distinguish between parents, it says that all files are binary equal.

• I do not have and never had an eol extension .
• To cancel the changes, nothing happens, the file is still registered as changed.
• hg parents show two parents for the file.

• hg stat shows the file as modified, for example.

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

• hg diff - git shows nothing, for example.

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

I tried this on two different machines on two separate clones, and I see the same thing.

Any other thoughts on how I can diagnose or fix this? Obviously something has changed, but if it does not appear in hg diff - git, how can I establish what it could be?

Update 2014/12/10:

I did a bit more checking the history of the two parent revisions, and I think I understand why this is getting confused.

• We have the original parent file added to version 1 by default.
• In the Apple branch, the file has been renamed to move it to a new location.
• A file has been added to the Orange branch to move it to a new location.

Thus, the file on both branches is identical to the binary and in the same place, but Mercurial supposedly puts it as a difference that needs to be combined because they arrived there in apparently different ways.

So then the question is:

Is there a way to retrospectively edit a move that is treated as adding and removing in a long declared change set (the new commit will be fine, but I can't edit the story), or do I just need to let it go through the merge?

Answer 1

Is there a way to retrospectively edit a move that is treated as adding and removing in a long declared change set (the new commit will be fine, but I can't edit the story)

Well ... sort of. Update the latest Orange update, in which the files have their old names (you can use hg bisect to find it if you are not sure exactly when it happened), do hg rename for the new names, commit, and then merge this into the current orange head . Mercurial should be smart enough to register files as properly renamed, and this will not cause conflicts (we know this because there was no more complex Apple / Orange merge).

or do I just need to let him go through the merger?

It is easier. The mercury merging algorithm is pretty smart. He can handle situations like this perfectly.

If you do not have a third branch in which files have never been moved, the second option is unlikely to cause a problem. If you have one, you should be fine while you merge it into a descendant of the Apple rename (or merge with that descendant). The main difficulty would be mergers with or from the orange branch.