Delete all local changesets and revert to tree
Version ControlMercurialDvcsHeadVersion Control Problem Overview
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.
Version Control Solutions
Solution 1 - Version Control
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())'
Solution 2 - Version Control
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.
Solution 3 - Version Control
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.
Solution 4 - Version Control
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.
Solution 5 - Version Control
Just delete everything you have on your local system and re-clone the remote repo.
Solution 6 - Version Control
hg strip 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 strip hg out OTHER_REPO_ALIAS --template "{rev} {author}\n" | grep YOUR_AUTHOR_NAME | cut -d " " -f 1
Solution 7 - Version Control
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.