addremove: restore the relative path printing when files are named

This fixes the previously mentioned issue with 7d5fcea60c78, and undoes its
corresponding test change.

The test change demonstrates the correctness when a file is specified (i.e. the
glob is required on Windows because relative paths use '\' and absolute paths
use '/').  It is admittedly very subtle, but there will be a more robust test in
the addremove -S v3 series.
This commit is contained in:
Matt Harbison 2014-12-04 23:08:27 -05:00
parent 25fa81d27a
commit e5bd4011a8
2 changed files with 3 additions and 4 deletions

View File

@ -730,11 +730,10 @@ def addremove(repo, pats=[], opts={}, dry_run=None, similarity=None):
toprint.update(deleted)
for abs in sorted(toprint):
if repo.ui.verbose or not m.exact(abs):
rel = m.rel(abs)
if abs in unknownset:
status = _('adding %s\n') % ((m.anypats() and rel) or abs)
status = _('adding %s\n') % m.uipath(abs)
else:
status = _('removing %s\n') % ((m.anypats() and rel) or abs)
status = _('removing %s\n') % m.uipath(abs)
repo.ui.status(status)
renames = _findrenames(repo, m, added + unknown, removed + deleted,

View File

@ -91,7 +91,7 @@ Issue1527: repeated addremove causes util.Abort
no copies found here (since the target isn't in d
$ hg addremove -s80 d
removing d/b
removing d/b (glob)
copies here