working directory state after failing update
Mads Kiilerich
mads at kiilerich.com
Tue Jul 20 09:57:36 CDT 2010
[mk at D610 hg]$ hg up -r null
0 files updated, 0 files merged, 1193 files removed, 0 files unresolved
[mk at D610 hg]$ ll
total 0
[mk at D610 hg]$ hg init mercurial
[mk at D610 hg]$ hg up -C
abort: path 'mercurial/__init__.py' is inside repo 'mercurial'
[mk at D610 hg]$ hg parent
[mk at D610 hg]$ hg st | head
? .hgignore
? .hgsigs
? .hgtags
? CONTRIBUTORS
? COPYING
? Makefile
? README
? contrib/bash_completion
? contrib/buildrpm
? contrib/check-code.py
[mk at D610 hg]$ hg up -C null
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
[mk at D610 hg]$ hg up -r 1
abort: untracked file in working directory differs from file in
requested revision: '.hgignore'
[mk at D610 hg]$ hg parent
[mk at D610 hg]$
A situation like that is not unlikely to happen when people moves stuff
to subrepos.
I was surprised that Mercurial left the files untracked in the working
directory. I would have expected it to first update the parent info and
mark all the not-yet-updated/deleted files as dirty, and then work
through that list and resolve them one by one in the working directory.
Well ... I can see that that is not how it is. We don't have a dirstate
state for "clean but outdated". Is that something you would like to see,
or what is your opinion on this?
/Mads
More information about the Mercurial-devel
mailing list