174

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.

StayOnTarget
  • 11,743
  • 10
  • 52
  • 81
Rory
  • 40,559
  • 52
  • 175
  • 261
  • 1
    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? – Lasse V. Karlsen Feb 10 '11 at 13:39
  • it's a separate step done with my build software. (I could have just used a command-line delete, but didn't.) – Rory Feb 10 '11 at 13:43
  • 1
    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. – Tim Post Feb 10 '11 at 13:53

5 Answers5

225

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.

Lasse V. Karlsen
  • 380,855
  • 102
  • 628
  • 825
  • 6
    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. – Rory Feb 10 '11 at 14:58
  • 4
    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). – Dave Aug 01 '11 at 21:17
  • 20
    If the purge extension is not activated, you can also use the command like this: `hg --config "extensions.purge=" purge --all` – Samuel Delisle Jun 08 '15 at 14:30
  • 6
    @csharptest.net `hg purge --all` just gave me a good headache, since it also erased my local configs, i.e.: database user / password etc. :) – VMC Apr 28 '16 at 05:42
  • @SamuelDelisle thank you good sir, I didn't want to do any config changes just for this one-time command in my script! – joonas.fi Jun 16 '16 at 13:39
  • 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. – Llorenç Pujol Ferriol Oct 09 '19 at 10:25
  • 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. – Lasse V. Karlsen Oct 09 '19 at 10:37
122
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.

Vadim Kotov
  • 8,084
  • 8
  • 48
  • 62
zerkms
  • 249,484
  • 69
  • 436
  • 539
  • 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... – Rory Feb 10 '11 at 13:41
  • 7
    @Rory: nope, `hg purge` is for unversioned files. – zerkms Feb 10 '11 at 13:42
  • 1
    I get this error when trying hg up -C: abort: You must specify a destination to update to, for example "hg goto main" – Geordie Dec 28 '22 at 19:30
12

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

Community
  • 1
  • 1
KCD
  • 9,873
  • 5
  • 66
  • 75
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.

John Lawrence Aspden
  • 17,124
  • 11
  • 67
  • 110
3

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"

Commit

2. Then, display ignored files. If you have uncommitted changes, hide them.

Show ignored files

3. Now, select all of them and click "Delete Unversioned".

Delete them

Done. It's a procedure that is far easier to remember than commandline stuff.

bytecode77
  • 14,163
  • 30
  • 110
  • 141
  • 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. – Jon Coombs Sep 13 '17 at 17:23