Reputation: 62588
working directory
Did a
hg commit (resulted in rev3)
Copied some directories inside ... changed some files. Did
hg add
hg commit (resulted in rev4 - tip)
How to get back exactly to the state of rev3. hg update 3
will change the files to the state they were in rev3, but it will also leave all the copied directories inside. I want to get the working directory without the copied directories and files, which were added after rev3.
Upvotes: 2
Views: 342
Reputation: 73808
Like Jon writes, Mercurial will normally try to clean up after itself. So when you hg update
you should get back exactly what you committed. What I guess you're seeing is the following behavior:
$ hg init repo
$ cd repo
$ echo "# some C program" > foo.c
$ hg add foo.c
$ hg commit -m first
$ mkdir dir
$ echo "$ other C program" > dir/bar.c
$ hg add dir/bar.c
$ hg commit -m second
$ echo "object file" > dir/bar.o
$ hg update 0
0 files updated, 0 files merged, 1 files removed, 0 files unresolved
$ ls
foo.c dir
$ ls dir
bar.o
So the untracked dir/bar.o
file has been left behind, but the tracked dir/bar.c
file has been correctly removed. That is: Mercurial wont delete untracked files since it doesn't know if they contain valuable data. This applies even if the files are ignored by a pattern in .hgignore
. If the directory had only contained the tracked dir/bar.c
file, then the directory would have been completely removed when you update to a revision where it isn't needed.
The normal way to clean up untracked files is to use the purge extension.
Upvotes: 1
Reputation: 1503869
That doesn't happen for me:
> hg init
> mkdir first
> jed first/foo.txt
> hg add
adding first/foo.txt
> hg commit -m asd
> mkdir second
> jed second/foo.txt
> hg add
adding second/foo.txt
> hg commit -m asd
> hg update 0
Now first
exists, but second
doesn't...
Are you sure you added everything in the new directories before your commit?
Upvotes: 2