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.
Related
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.
I'm new to Mercurial and MercurialEclipse, and I think I'm not quite understanding this:
After I pull from the central repository (with Update After Pull selected), it is my understanding that all files are loaded form the central repo to my local repo. However, after I pull, I'm seeing the following:
Doesn't the star icon indicate that there are differences between my local copy and the central copy?
What am I missing here? How do I make sure that my files are the most recent copies?
Try right-clicking on your Eclipse project and select Team --> Refresh Status. I often have to do that for the status icons to be updated.
Edit: if you want to override all local changes, select the checkbox "Clean update (override local changes)" in the Pull dialog of Eclipse.
When you update it merges the local changes you have with the changes in the revision you are updating to. In the update dialog if you select the "force" checkbox it will revert any uncommitted changes. Other ways to remove your local changes are updating by right clicking on a revision in the history view and selecting "switch to", or use the "revert" dialog.
I made the mistake about 3 months ago of doing a force push to Mercurial, and somehow, it has remembered that...so whenever I push now, it forces it by default:
% hg --repository C:\Projects\Sonic\DDSF push --force ssh://192.168.52.2:22//hg/DDSF
How do I get rid of this setting and go back to the regular pushes?
My team gets mad at me daily because I'm constantly creating new heads and breaking stuff :(
I've checked my .hgrc file and its not there. I've also re-installed the TortoiseHg client in hopes that it would solve this problem but it hasn't.
In TortoiseHG, you can disable the setting as follows:
Go to the "Synchronize" screen via the menu View -> Synchronize or by clicking this button in the toolbar:
Click the "Options" button under the list of commits:
In the options window, there's a checkbox for the "force push" setting:
By the way, when force is enabled, you should already see this below the "Options" button in step two:
Simple question: is there a way to revert --all from TortoiseHg workbench? I see how to revert an individual file. Ideally, I could click on a revision, and from the right mouse menu find a "revert all" item.
I'm using TortoiseHg 2.8 on a Ubuntu box.
EDIT I should have provided more details on my question to provide some context. Let me describe the particular use case:
I want to put my working directory back to the state of a past commit so I can generate output from the executable that I know was "good". Once I've generated that output, I want to go back to the tip and continue my development, keeping this history linear. From the command line, I did "hg revert --all --rev 22", generated the output, then "hg revert --all", which did what I wanted. "hg update" will create a history with a branch (if I'm understanding correctly). FWIW there is an "update" button in TortoiseHg (in the box where the list of files is shown) as well as a right-mouse menu item on a given revision.
To set the working directory to match the state of a given changeset (which could be tip), you can use Update:
Right click on the changeset you want to 'revert' to.
Select "Update"
Check the "Discard local changes" checkbox
Click Update
It would be hg update -r changeset -C in the console.
Now you can create the output from the 'state' of the working directory at that point in history (i.e. from the executable at that changeset). If you don't make any commits here there will be no changeset created and therefore nothing is added to the repo history.
Once you have the output to your satisfaction, you can update again to the tip of development via the same process and continue your work:
Right click on the tip of development.
Select "Update"
Check the "Discard local changes" checkbox
Click update
The benefit of using update over revert is that Tortoise will explicitly display the parent of the working directory as the changeset it history. Under revert it could be very easy to revert the files and lose track of which changeset you had reverted to and which part of history you occupied.
(This is assuming that you want to move to that point in the history. If you need to create a changeset that undoes a prior changeset, look into backout, though I'm not sure if that is available in Tortoise.)
You can select all modified files in the list with Ctrl+A and then select "Revert" from context menu.
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.