When using Mercurial, how do you undo all changes in the working directory since the last commit? It seems like this would be a simple thing, but it's escaping me.
For example, let's say I have 4 commits. Then, I make some changes to my code. Then I decide that my changes are bad and I just want to go back to the state of the code at my last commit. So, I think I should do:
hg update 4
with 4 being the revision # of my latest commit. But, Mercurial doesn't change any of the files in my working directory. Why not?
hg revert will do the trick.
It will revert you to the last commit.
--all will revert all files.
See the link for the Man Page description of it.
hg update is usually used to refresh your working directory after you pull from a different repo or swap branches. hg up myawesomebranch. It also can be used to revert to a specific version. hg up -r 12.
An alternative solution to hg revert is hg update -C. You can discard your local changes and update to some revision using this single command.
I usually prefer typing hg up -C because it's shorter than hg revert --all --no-backup :)
hg revert is your friend:
hg revert --all
hg update merges your changes to your current working copy with the target revision. Merging the latest revision with your changed files (=current working copy) results in the same changes that you already have, i.e., it does nothing :-)
If you want to read up on Mercurial, I'd recommend the very awesome tutorial Hg Init.
hg revert --all
and then
hg pull -u
works for me
Related
Last night I started a merge; and forgot to commit it.
Later on I made some changes to the working copy.
Today I no longer want that merge at all (as I'll merge on a newer revision), but I want to keep the local working changes. The changes are independent of any merge resolution.
How can the local changes be kept (and/or reapplied later) while aborting the current merge?
Using shelve on the local changes was not allowed:
$ hg shelve foo/bar
abort: cannot shelve while merging
Using an hg up -C, the normal way to 'abort a merge', would eliminate the local changes.
This is not like How to 'hg merge' without affecting the working directory? because a merge has already been started, just not committed. Answers that involve finishing the commit first, and then picking changes is suitable if such can be shown simply, although the question is focused about 'abort without the commit'.
The easiest solution is probably to record the changes temporarily in a secret commit and then to revert to that commit, e.g.:
hg resolve -m -a # mark all files as resolved
hg commit -s -m "Savepoint." # Temporary commit.
hg update .^ # Back to original revision.
# (Use ".^" in cmd.exe on Windows.)
hg revert -r tip --all # Revert files to saved commit.
hg diff # Verify that you've got all the changes.
hg strip -r tip --keep # And discard the temporary commit.
We're using a secret commit here so that it doesn't accidentally get pushed if you forget to strip it (or if you plan to keep it around afterwards).
If you're using the evolve extension, hg prune -r tip is to be preferred over hg strip -r tip --keep, as it still keeps the temporary commit around (hidden) in case you need to refer to it later.
This seems like it should be really easy, but I can't find anything that directly addresses it in my searching. I have a mercurial repo with subrepos, I have deleted one of the subrepos (the whole folder). How do I reclone that subrepo now? I could do it manually but surely there's a hg command that does the job?
Use the Clean parameter in your hg update to make it pull the subrepo again.
hg update -C
Beware that clean will discard any uncommitted changes in your working directory, so shelve or commit anything you want to keep before doing it.
I guess I'm learning somewhat backwards. I'm very comfortable with git and never used mercurial until my most recent project.
One of the things that bothers me is that sometimes I can't seem to refresh my development environment because of un-tracked file errors. I really don't care whether files are tracked/untracked on the development server. I'd just like to be able to pull the most recent state of the repo from bitbucket.
Unfortunately, I sometimes end up resorting to nuking the app and re-cloning. Normally this wouldn't be that big of a deal but there are dependencies that I need to add back to the app each time I do this because they are not stored in the repo.
With git I would run...
git reset --hard; git checkout master -f; git pull; git checkout origin/master -f
What's the mercurial equivalent? I've tried...
hg revert --all; hg pull; hg update;
Which seems to work as I would expect it sometimes. When it doesn't work it aborts due to the untracked file errors. I'm looking for something that works all the time.
hg up --clean
That's all there is to it. (hg up rather than hg update because hg is cooler than git and allows unique abbreviations. I dislike the way when I'm forced to use git it doesn't accept git ci like a sane version control system. I know I could make an alias... but I haven't ever got round to it partially as I don't use it very often at all)
hg help [command] (or hg [command] --help) is useful. The help for revert mentions that you probably want to use hg update -r rev or hg update --clean . instead.
This will only change tracked files. Untracked files will be left alone, which I think is what you want.
I run hg pull which added new changes to my repository. Before updating my working directory with the new changes i would like to see these new files/changes. I believe in SVN i used svn st -u but how is it done in Mercurial?
Before you even pull you can use:
hg incoming --stat
to see a summary of changes or
hg incoming --patch
to see the actual deltas.
After pulling (but before updating!) you can do:
hg status --rev tip
to see a list of the changed files, or
hg diff --rev tip
to see a summary of the changes, or
hg diff -r tip
to see the combined diff.
(After pulling the changes via hg pull) you can run hg status --rev tip to show an output similar to svn st -u.
There is also hg incoming (alias hg in; additionally hg outgoing/hg out) which can be used before pulling which will show you the revisions which will be pulled. At times this can be useful.
I'm using Mercurial and I've got into a terrible mess locally, with three heads. I can't push, and I just want to delete all my local changes and commits and start again with totally clean code and a clean history.
In other words, I want to end up with (a) exactly the same code locally as exists in the tip of the remote branch and (b) no history of any local commits.
I know hg update -C overwrites any local changes. But how do I delete any local commits?
To be clear, I have no interest in preserving any of the work I've done locally. I just want the simplest way to revert back to a totally clean local checkout.
When the simplest way (a new hg clone) isn't practical, I use hg strip:
% hg outgoing -l 1
% hg strip $rev # replace $rev with the revision number from outgoing
Repeat until hg outgoing stays quiet. Note that hg strip $rev obliterates $rev and all its descendants.
Note that you may have to first enable strip in your Mercurial settings.
PS: an even smarter approach is to use the revset language, and do:
% hg strip 'roots(outgoing())'
You'll want to make a local clone where you preserve only the changesets that are also present in the remote repository. Use TortoiseHg, hg log or similar to figure out which of your revisions is that lastest revision you didn't make (the one before the mess started). Using hg outgoing can help here -- it will list all the changesets you made -- pick a revision number earlier than any of those.
If the target revision is called good and your clone is called foo, then do:
hg clone -r good foo foo-clean
This will be a fast, local operation -- there is no reason to download everything again. The foo-clean clone will only contain changesets up to revision good. You can now replace foo-clean/.hg/hgrc with foo/.hg/hgrc in order to preserve your repository-local settings such as the default push/pull path.
When you are satisfied that foo-clean has everything you need from foo, then simply delete foo and rename foo-clean to foo. Do a hg pull to get any new changesets from the remote repository into your clone and continue like normal.
If nobody has pushed new changesets to the remote repository, then it is very simple to determine which revision you want to use as good above: hg id default will tell you the ID of the tip in the remote repository.
Ok. So just delete all the local stuff, hg init the new local repository and hg pull the latest tip you have. Don't forget to hg update after this.
You may use
hg strip revision
to kill any revision and its subtree in your local repository.
https://www.mercurial-scm.org/wiki/Strip
But don't try to use it for anything that has been already pushed.
Just delete everything you have on your local system and re-clone the remote repo.
hg strip `hg out --template "{rev} {author}\n" | grep YOUR_AUTHOR_NAME | cut -d " " -f 1`
does the trick for me.
It strips all revisions that aren't pushed to the default repository which are created with your author name.
You can also use this style to make it not checking with the default repository but with another Repository
hg strip `hg out OTHER_REPO_ALIAS --template "{rev} {author}\n" | grep YOUR_AUTHOR_NAME | cut -d " " -f 1`
If you are using TortoiseHg, one simple way to get out of a (small) mess is to first update to the latest revision, then select your changesets and initiate "merge with local". When the merge dialogue appears, simply click the little '+' icon to reveal some extra options, one of which is "discard changesets from merge target (other) revision". Doing this will mean your changesets will still be in the repo and get pushed, but will have no effect, because they will be discarded in the merge. If you have a lot of changesets spanning many heads, you might not want to pollute the repo this way, but it's a simple fix and worth considering if the changesets you are discarding contain data that you may later want to reference.