TortoiseHG: undoing Guess Rename --> Accept Match - mercurial

I'm using TortoiseHG and am trying to handle a renamed file. Unfortunately, I accidentally clicked Accept Match for one of the files and want to undo it. How do I do so without hurting the files I'm trying to commit?

In the commit dialog you can right-click on the added file, and select forget. Then the file is no longer marked as copy. When you want the file in the commit, you can add this file again.

I'm not sure what's different but for me, there is no "forget" option in this situation.
What worked for me is choosing "revert" on the added file (the one marked as 'A'). This removes the rename, but also restores the original file. (If you renamed asdf.txt to fdsa.txt you will now have two files with those names.)
You then have to manually delete the restored file, and you should be back where you started. Note that I find it's safer to delete files with Windows file explorer, since they will end up in the recycle bin. Files deleted from thg are deleted permanently.

Related

Is there any way to recover source code from a deleted revision history?

I want to restore the source code that I accidentally deleted, but I can't find it in the revision history.
Is it possible to revert to a version that is not in the history?
Every change saved in your project should appear in the version history
By using the legacy editor if you click on your file.gs and then click File > See version history you'll be able to Restore this version in the editor. Otherwise it means that you haven't saved a change made in your code.
If you accidentally deleted a file not only the code as per the documentation says this file can't be recovered despite of using clasp.
In order to avoid accidentally deleted files
I'd recommend you to use a system version control such as Git in conjunction with Clasp as you already used, in doing so you can keep the code up to date either in Git or your Script Project.

How to stop mercurial from syncing an EXISTING project file

So the problem is that all developers need different settings for their local testing, but the settings file is part of the project (unlike the nbproject folder for example that we all ignore). I know about .htignore, but the filter only applies to files that are not part of the project.
If I forget the file, then this removes it from the "global" repository, where we have a "holder" version of the settings file.
Right now we just don't commit that file, but every now and then somebody forgets and pushes his own settings, which then are synced back to other developers and it's a constant pain. We just want to "automatically" not push that file. Is there a solution to this? Are we doing something wrong?
You could add a precommit hook that gives an error every time you try to commit this particular file.
To handle the case of developers that forget to setup such a hook, you can also add a serverside hook that will reject their push.

TortoiseHg: What is the behavior of checking/unchecking a deleted file during commit?

During a commit, I'm not clear on what the behavior is when you check or uncheck a checkbox next to a file that was deleted. See image.
Checking the check box means that you include the change in the next commit. For example, checking a modified file will tell TortoiseHg to commit the modifications of the file. It is also possible, in newer versions of TortoiseHg, to cherry-pick the individual changes within the file itself, by checking the differences in the right-side panel.
For the removed file, it is the same thing. Checking the file tells TortoiseHg that the removal of the file has to be taken into account in the next commit, so the file will be removed in the commit. Leaving it unchecked, on the other hand, will prevent the file from being removed in the repo, and the file will remain as an uncommitted change after the commit.
And finally, if you check an untracked file, TortoiseHg will add it in the repository for you in the next commit.

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.
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.

telling mercurial to ignore a file when merging and updating

I want mercurial to ignore my own local copy of log/development.log (I am on RoR).
I used "hg forget filename" to forget the file, and then committed that change.
It seems to be successful now.. but every time I merge with other changesets now, I see
remote changed log/development.log which local deleted
use (c)hanged version or leave (d)eleted?
what am I doing wrong? how can I make this msg go away? I just want my local copy to be separate from the copy in the repository.
Thank you...
If you deleted the file in your line, and you merge it with the one that still has this file, this message is to be expected. The only way to get rid of it is to remove this file from the repos/branches you're merging with (or get their owners to remove it, if you don't control them).
And then never commit a temporary log file into the repository ever again.