CODEWITHSUNDEEP
mercurial
user247702
user247702

Reputation: 24212

Binary equal files show as modified, unable to revert

I suddenly have a few files that show as modified, but KDiff says they are binary equal. Reverting and discarding those changes does nothing.

Somehow, the eol extension is enabled and when I try to disable it, I can't view that one repo's Working Directory in TortoiseHg. An error appears:

[Error 6] The handle is invalid

When using the command line hg status, this error appears:

'cleverencode:' is not recognized as an internal or external command, operable program or batch file.

When using hg revert myfile, .orig files are generated but the files still appear as modified and the same error from above appears.

When updating to a previous commit, a whole lot of other files get in the same situation like those few I have now.

If necessary, I can throw away this clone and make a new clone, but it would be nice if this can be resolved without doing so.

Upvotes: 4

Views: 1144

Answers (2)

Edg
Edg

Reputation: 9

I found that the cleverencode did not work for me -- I didn't have it in my mercurial.ini. My case was also a binary file that mysteriously got marked as modified and would not go away with revert, clean, etc...

I did some poking around and fixed it: there's a repo/.hg/largefiles directory. I believe mercurial keeps this as a local cache of binary files in order to revert back changes. In this directory you'll see a bunch of file names in hex. In TortoiseHg "browse" your binary file causing the problem. It'll show you the hex code corresponding to your binary. Find that file in the largefiles directory and delete it.

You should now be able to revert the file back to unchanged. I think mercurial uses the largefiles version to revert first. Then, when this version doesn't match the repo version it gets marked as modified (in my case my binary somehow got truncated to 0 length) and will never go away.

You can also just delete the largefiles dir altogether if you can't match the hex name. It will get recreated as needed. I think the only repercussion is that it's take longer to do some binary file operations since it will have to go to the server.

Upvotes: 0

user247702
user247702

Reputation: 24212

Was able to solve it.

My global mercurial.ini had some lines with cleverencode in them. After removing those, the issue has disappeared. Enabling/disabling the eol extension also doesn't seem to cause any issues any more.

I suspect the troublemaker was Atlassian's SourceTree, I had installed an update yesterday and it asked if automatic line ending handling should be enabled. I'm quite sure I unchecked it, regardless, it seems to have mixed eol config with win32text config.

See also: [SRCTREEWIN-708] Possible error with Mercurial line ending handling configuration - Atlassian JIRA

Upvotes: 9

Related Questions