I'm a new user of tortoisehg and accidently I typed the command 'hg update -C -r 3' and a lot of files removed. Can I undo this command? I'm really desperate, thanks for any help and so sorry for poor English.
When you updated to an older revision, your TortoiseHg will probably look like this:
So you simply need to go to your tip (most recent revision) and click update. All your "lost" files will be "restored" again. The "" are there because nothing is really lost just because you update to a different revision. Every revision is stored in the repository.
But wary that uncommitted changes will be lost when you update to a different revision, but you have to confirm that explicitly!
Related
I am new to Mercurial. I had made some some changes in the code in some of the files and i hadn't committed them yet. but when I did hg update -c <branch-name>, all my code changes were gone. Is there any way I can get my code changes back or am I screwed?
Are you perhaps using a very, very, old version of Mercurial?
The help for hg update shows that -c won't discard uncommitted changes:
-C --clean discard uncommitted changes (no backup)
-c --check update across branches if no uncommitted changes
That's been the case for at least four years. If you try to update to a revision that would discard your local changes Mercurial warns you:
ry4an#four:~/test$ hg checkout 0
abort: uncommitted changes
(commit or update --clean to discard changes)
If you used -c it should have done nothing. If you used -C you should find whomever suggested you do so and yell at them.
Sorry for your loss. :(
Unfortunately no, as explained in the update help (hg help update), --clean don't create backup.
Check if you can get the old version of your files with your text editor with CTRL + Z, it already saved my life.
Is it possible to know when a certain commit was pulled from a distant repository and the files updated with Mercurial ?
More precisely, I made a hg pull -u a few days ago, and now I'd like to know if this pull downloaded only the last commit, or if there were some commits that had not been pulled yet, making my last pull getting them as well.
hg log seems to give the dates of the commits, but nothing about the updates. Is this information anywhere ?
This information is not recorded by Mercurial. A Mercurial repository is just a container for changesets and Mercurial does not store how (or when) the changesets entered the repository.
You can setup hooks for this, though you would have to build the scripts yourself. A very rudimentary system would be
[hooks]
pre-pull = (date; hg root; hg tip) >> ~/.pull-log
post-pull = hg tip >> ~/.pull-log
This would record the current date, the current repository, and the current tip in ~/.pull-log just before every hg pull. After the pull the new tip is recorded. You could build scripts that parse the log file to extract information about what each pull did.
hg log seems to give the dates of the commits, but nothing about the updates
Yes, hg log is only concerned with the stored history (changesets) and working copy operations like updating is not part of recorded history.
Finally, let me mention that this is the first time I've seen someone ask for a "pull log". However, the opposite is quite common: there are scripts for maintaining a "push log" on a server to see who pushed what and when. This is done by Mozilla among others. See this README for some starting instructions.
If you want to log when and with which revision hg update was used to update the code, then use these hooks:
[hooks]
pre-update = (echo "---------------------------------"; date --rfc-3339=s; hg root; echo "pre-update:"; hg identify --id --branch) >> .hgupdates
post-update = (echo "post-update:"; hg identify --id --branch) >> .hgupdates
the above hooks produce a log entry like this for each time hg update is run:
2015-12-23 00:44:31+02:00
/var/www/my/project
pre-update:
802120d1d3a0 somebranch
post-update:
302720d1d3d2 otherbranch
This also works when hg update is run without a specific revision flag (-r) set
When getting the latest code from a Mercurial repo on the command line, if there are changesets that need to be merged Mercurial raises a warning:
hg up
abort: crosses branches (merge branches or use --check to force update)
This is what I expect, and from the Mercurial book it says "Mercurial is telling us that the hg update command won't do a merge; it won't update the working directory when it thinks we might want to do a merge, unless we force it to do so." At this point I know I need to merge.
How can I get the same behaviour using TortoiseHg? When I hit "Update", it happily updates me to the most recent changeset. Is there a way to warn me that a merge is probably needed? The "Always merge (when possible)" option seems to only apply when you have uncommitted changes.
The reason you get an error from hg update on the command-line is that it doesn't know which revision to pick. There are 2 divergent default heads.
If you were to execute hg update -r <specific rev>, the command completes without error.
When using TortoiseHg, you update by:
right-clicking a specific changeset
selecting Update...
This translates to hg update -r <rev>, so there is no error.
Using TortoiseHg, you always have the revision graph in front of you. The graph shows when newly pulled changesets create a new head.
The Mercurial abort you are seeing is occurring because you have outstanding (ie: non-committed) changes in your working directory, are trying to perform an update, and Mercurial has decided that you should probably perform a merge instead.
TortoiseHg should also warn you about this, but it will do so in a different way. It will spawn a dialogue that asks if you want to Discard, Merge, or Shelve your outstanding changes. This is what it looks like in TortoiseHg v2.X.X, but it should be similar in v1.1.X:
If you're not seeing this in TortoiseHg, you may not have any outstanding changes. Try it again - are you seeing these options?
I'm moving a build process to use mercurial and want to get the working directory back to the state of the tip revision. Earlier runs of the build process will have modified some files and added some files that I don't want to commit, so I have local changes and files that aren't added to the repository.
What's the easiest way to discard all that and get a clean working directory that has the latest revision?
Currently I'm doing this:
hg revert --all
<build command here to delete the contents of the working directory, except the .hg folder.>
hg pull
hg update -r MY_BRANCH
but it seems like there should be a simpler way.
I want to do the equivalent of deleting the repo, doing a fresh clone, and an update. But the repo is too big for that to be fast enough.
Those steps should be able to be shortened down to:
hg pull
hg update -r MY_BRANCH -C
The -C flag tells the update command to discard all local changes before updating.
However, this might still leave untracked files in your repository. It sounds like you want to get rid of those as well, so I would use the purge extension for that:
hg pull
hg update -r MY_BRANCH -C
hg purge
In any case, there is no single one command you can ask Mercurial to perform that will do everything you want here, except if you change the process to that "full clone" method that you say you can't do.
hg up -C
This will remove all the changes and update to the latest head in the current branch.
And you can turn on purge extension to be able to remove all unversioned files too.
To delete untracked on *nix without the purge extension you can use
hg pull
hg update -r MY_BRANCH -C
hg status -un|xargs rm
Which is using
update -r --rev REV revision
update -C --clean discard uncommitted changes (no backup)
status -u --unknown show only unknown (not tracked) files
status -n --no-status hide status prefix
hg status will show you all the new files, and then you can just rm them.
Normally I want to get rid of ignored and unversioned files, so:
hg status -iu # to show
hg status -iun0 | xargs -r0 rm # to destroy
And then follow that with:
hg update -C -r xxxxx
which puts all the versioned files in the right state for revision xxxx
To follow the Stack Overflow tradition of telling you that you don't want to do this, I often find that this "Nuclear Option" has destroyed stuff I care about.
The right way to do it is to have a 'make clean' option in your build process, and maybe a 'make reallyclean' and 'make distclean' too.
If you're looking for a method that's easy, then you might want to try this.
I for myself can hardly remember commandlines for all of my tools, so I tend to do it using the UI:
1. First, select "commit"
2. Then, display ignored files. If you have uncommitted changes, hide them.
3. Now, select all of them and click "Delete Unversioned".
Done. It's a procedure that is far easier to remember than commandline stuff.
Accidentally, by using a GUI as opposed to CLI, I removed every file in a Mercurial project.
I recovered with Revert ok and lost some work, which as I have time machine I could easily get back. But is there a way of un-remove/undelete such files? Trawled through the manual and googled but cannot see anything. Any plugins?
I am probably answering my own question here but the files were gone from the directory and were not in the trash to recover so I am assuming Remove is irrevocable?
p.s. I know that hg forget or hg remove -Af will remove without deleting from the directory but my question has to do with the error I made as opposed to cool thinking the action through.
First, use hg grep to find the deleted file you wish to recover. The output of this command will show you the last revision for which the file was present, and the path to the deleted file.
Second, run hg revert -r <revision number> <path to deleted file>
The deleted file will now be in your working copy, ready to be committed back into head.
Quote from comment:
I set up a repository, committed all, Removed and then committed again
If this is the case then you just need to update the working directory to the previous revision:
$ hg update -C -r-2
Note the negative revision number. If the files you deleted aren't in the previous revision, you can find them by using:
$ hg log -v
For Mercurial 1.6 and above
If you know the name of the delete file you can find its revision easily with:
hg log -r "removes('NAME.c')"
This will give you the revision in witch a file called NAME.c (in the root) is deleted.
Then you can revert the file to the previous revision with (like other answers):
hg revert -r <revision number> <path to deleted file>
You can use a file name pattern instead to adapt to what you know, for example you can use **/NAME.c to search in all directories. You can read about it in File Name Patters. And use this link to know about the new revset specifications.
Well this worked for me.
hg revert -r revision pathToTheFile
An addition to the accepted answer - this is faster if you want to undo all removals in a commit. I deleted a large folder with a few hundred files in it and did hg addremove, which was not at all my intent, so had to undo all of those deletes.
Using Find deleted files in Mercurial repository history, quickly? + xargs + tr, revert all revision -3 removals to the version from revision -4:
hg log -r -3 --template "{rev}: {file_dels}\n" | tr ' ' '\n' | xargs hg revert -r -4
Note that this will fail if any of your files have spaces in the name; http://hgbook.red-bean.com/read/customizing-the-output-of-mercurial.html doesn't appear to have any templates where {file_dels} is split by \n at the moment.
You can undo the last commit on a repo with hg rollback. There's only one level of rollback available, so if you did the remove with more than one commit, this won't completely undo your change. This only works on your local repository, so if you've pushed you won't be able to undo it in the remote repo.
You can remove committed revisions using the hg strip command, which is provided by the mq (Mercurial Queues) extension. This should give you back your files.
Make a backup before trying that out, because it will alter Mercurial's database of changesets.
The following worked for me.
hg revert -r <Revision Number> <File Name>
(Optional, to revert all files)
hg revert -r <Revision Number> --all
The below method is straightforward and so stupid that it cannot go wrong.
If you have deleted or renamed multiple files, it will be ok.
hg clone mydirectory mydirectory1
and now you start mc (or Far Manager) and compare what it was vs what it has become.
when it's done, just delete mydirectory1.