I love PyCharm (and IntelliJ). However, in PyCharm for Max OSX, using Mercurial VCS, I get what I call "phantom files" in my changelists as I work. I don't know why they appear and I don't know how to stop them from appearing. By "phantom files", I mean files that actually exist, but are shown in green font, and Show Diff shows them as having an empty file on the left, and the complete file on the right. Sometimes they're files I've actually changed since last commit, sometimes not. If I've changed the file, the file appears twice in the changelist, once as a phantom file in green font, and again in blue font where Show Diff shows the actual updates.
Related
Every time I restart Tortoise HG it resets the set of selected file filters:
The "ignored" and "subrep" items always come back CHECKED even though my preference is to leave them off.
Most THG settings end up in Mercurial.ini but as far as I can tell this one isn't being saved at all. Is there anything I can do to make it so?
I'm using:
TortoiseHg
version 5.9.2
with Mercurial-5.9.2, Python-2.7.18, PyQt-5.13.2, Qt-5.9.9
but this has happened in every version I can remember.
OllyDbg - there are several patches applied but it still says that file was unmodified and doesn't save changes of patches to modded *.exe . Somehow before the addition of each new patch it saves ok with notice of changing the file, but with next it doesn't. And with the third I don't know how to overcome it. How to save them - am I doing something wrong?
The message
Basing on your comments - There is no such Save to file or Edit -> Save to file when you right click in the CPU window. You are doing somethng wrong.
The correct way to save the patches to new file is:
Open CPU window
Right click -> Copy to executable -> All modifications
Click Copy all in the new window
In the new window Right click -> Save file
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.
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
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.
I've a file in a folder and I don't know anything about this file (how it's generated and updated) because it comes from an application running on my system of which I don't have the source code.
The file format is clearly json and I successfully created an hard link to it (using the shell command ln file hardLinkToFile) and placed it on another directory.
At this point I check the "2" files and they are exactly the same as expected, but when I perform an action in the application that cause an update of the original file the hard link doesn't get updated.
Any idea on how I can solve this problem?
UPDATE: As pointed out by both Vlad Lazarenko and mvds the file probably get deleted and a new one is created, is there something I can do to obtain a solution equivalent to the hard-link one I thought initially about?
If a hard link is not getting updated, it means that application is removing the old file and creates a new one. Thus, you still have a hard copy of the previous file, but new file has a totally different inode, though path is still the same. You can verify it simply by changing the content of that file yourself - the link should get updated.
I am getting the same behavior in TextEdit, but not in TextMate. I would suspect this is due to the revision control built in to OS X Lions document architecture. TextEdit uses versioning, while TextMate does not. Most likely this function replaces the file instead of changing it, as described by #Vlad Lazarenko.
#Vlad and Francesco. It's really in this way. I verified that vi leaves the inode unchanged and the src and dest file are both changed, while e.g. the kate editor doesn't and I was getting mad to understand why the changes I made in the src file weren't also in the dest file.
You can easily check this with the command ls -li srcfile destfile before editing one of them with each editor I mentioned.
By the way it's not nice that the hard link are application dependent
I guess it is a bit too late...
Anyways, accidentally I found that, if you change the default app for the file, the hard link gets separated from original file. Even if you click on change all and do not relate to that specific file.
How can I browse the history of a chunk of a file, or the whole file if only that is possible, oven though the file was moved?
For example, file r/a/b.txt was moved to r/b.txt but had a history while in r/a,and I would like to see that history, if possible focused on a certain chunk/set of lines of the file.
You see the history of a file with
hg log --follow your-file
This will simply list the changesets that touch the given file. You can add --patch if you want to see the patches along with the log messages.
I don't know of a tool that can focus on a particular hunk. The closest is the annotate command. I always use it from TortoiseHg (works on all Windows, Mac, and Linux) which allows you to right-click on a given line and annotate the parent changeset of the changeset that touched the line. That makes it really convenient to "peel off" layers of history in the file.