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