Discard all and get clean copy of latest revision?

Question

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.

Solution 1

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.

Solution 2

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.

Solution 3

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

Solution 4

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.

Solution 5

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.

View more solutions

Comments

[Lasse V. Karlsen]

Is "(delete the contents ...)" a comment to the "revert --all" command or a step you perform? I ask because "hg update" will only update files that changed. If you remove other files before updating, you won't get those back unless you update back to the null-revision (hg update 00) and then back up to the tip. Why isn't hg revert --all enough to get back to a consistent working folder state before pulling and updating?

[irag10]

it's a separate step done with my build software. (I could have just used a command-line delete, but didn't.)

[Tim Post]

You might find the archive command to be useful in the future. For instance, you could hg archive ../newbuild, and a snapshot of your repository at the last hg update will be placed there. I typically do that for nightly builds just so I don't risk cluttering my repo. Just delete the build directory when you no longer need it.

[irag10]

Does that include un-tracked files? I had some problems with those in other commands I was trying. I'll give it a try now...

[zerkms]

@Rory: nope, hg purge is for unversioned files.

[irag10]

Thanks, it was the 'purge' that I needed. The update -C doesn't get rid of untracked files, which is the main thing I was struggling with.

[Dave]

You can use TortoiseHg to purge as well. You just have to turn the extension on in the workbench's settings (or edit mercurial.ini).

[Samuel Delisle]

If the purge extension is not activated, you can also use the command like this: hg --config "extensions.purge=" purge --all

[VMC]

@csharptest.net hg purge --all just gave me a good headache, since it also erased my local configs, i.e.: database user / password etc. :)

[joonas.fi]

@SamuelDelisle thank you good sir, I didn't want to do any config changes just for this one-time command in my script!

[Jon Coombs]

I'm not sure (I use SourceTree myself), but these screenshots appear to be from TortoiseHg Workbench. In general, I think UI-based solutions are helpful, but this answer needs better labeling. Also, "hide them" sounds a bit vague to me.

[Llorenç Pujol Ferriol]

Don't use hg purge --all. In my case it removed all node_modules and other files that should be ignored, since they are on .hgignore.

[Lasse V. Karlsen]

Since OP requested something similar to deleting the repository and recloning, that's what I provided. If one doesn't want to get a completely clean slate, then I agree, purge is something one should leave out.