Binary equal files are displayed as modified, unable to return

I suddenly got a few files that show as modified, but KDiff says they are binary equal. Undoing and discarding these changes does nothing.

Be that as it may, the eol extension is enabled, and when I try to disable it, I cannot view this one repo desktop in TortoiseHg. An error message will appear:

[Error 6] Invalid handle

When using the hg status command line, the following message appears:

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

When using hg revert myfile , .orig files are generated, but the files are still showing as modified, and the same error appears on top.

When upgrading to a previous commit, many other files end up in the same situation as the ones I have.

If necessary, I can discard this clone and create a new clone, but it would be nice if it could be solved without this.

+4
source share
2 answers

I managed to solve the problem.

In my global mercurial.ini there were several lines with cleverencode . After fixing the problem, the problem disappeared. Enabling / disabling the eol extension also no longer causes any problems.

I suspect the troublemaker was an Atlassian SourceTree, I installed an update yesterday, and he asked if automatic line ending processing should be allowed. I am quite sure that I disabled it, despite the fact that it has a mixed eol configuration with win32text configuration.

See also: [SRCTREEWIN-708] Possible error with setting up Mercurial line ending processing - Atlassian JIRA

+9
source

I found that cleverencode does not work for me - I do not have it in my mercurial.ini. My case was also a binary file that was mysteriously marked as modified and will not disappear with return, clean, etc.

I thought a little and fixed it: there is a repo / .hg / largefiles directory. I believe mercurial saves this as a local binary cache to push back the changes. In this directory you will see a bunch of file names in hexadecimal format. In TortoiseHg, β€œbrowse” your binary for the problem. It will show you the hexadecimal code corresponding to your binary. Locate this file in the large files directory and delete it.

Now you can return the file back without changes. I think mercurial uses the version of large files to return first. Then, when this version does not match the repo version, it becomes marked as modified (in my case, my binary code was somehow cut to 0 length) and will never disappear.

You can also simply delete the largefiles file altogether if you cannot match the hex name. It will be recreated as needed. I think that the only consequence is that some operations with binary files take longer because it will have to go to the server.

0
source

Source: https://habr.com/ru/post/1488660/


All Articles