[PATCH 4 of 9 V2] addremove: warn when addremove fails to operate on a named path

Martin von Zweigbergk martinvonz at google.com
Tue Dec 2 23:24:48 UTC 2014


On Sat Nov 29 2014 at 9:53:34 PM Matt Harbison <matt_harbison at yahoo.com>
wrote:

> # HG changeset patch
> # User Matt Harbison <matt_harbison at yahoo.com>
> # Date 1417030056 18000
> #      Wed Nov 26 14:27:36 2014 -0500
> # Node ID 9559f266ac03e53d20b2a2035bf5e417f37b79d3
> # Parent  37af995c0feea059692cc4ed423febb7c722a808
> addremove: warn when addremove fails to operate on a named path
>
> It looks like a bad path is the only mode of failure for addremove.  This
> warning is probably useful for the standalone command, but more important
> for
> 'commit -A'.  That command doesn't currently abort if the addremove fails,
> but
> it will be made to do so prior to adding subrepo support, since not all
> subrepos
> will support addremove.  We could just abort here, but it looks like
> addremove
> has always silently ignored bad paths, except for the exit code.
>
> diff --git a/mercurial/scmutil.py b/mercurial/scmutil.py
> --- a/mercurial/scmutil.py
> +++ b/mercurial/scmutil.py
> @@ -721,9 +721,15 @@
>          similarity = float(opts.get('similarity') or 0)
>
>      rejected = []
> -    m.bad = lambda x, y: rejected.append(x)
> +    origbad = m.bad
> +    def badfn(f, msg):
> +        if f in m.files():
>

What is this check for? The only case I can think of is so 'hg addremove
dir/' will not report 'dir: Permission denied'. It's unclear whether we
want to prevent that. I saw that it's the done in the same way at the end
of addremove().


> +            origbad(f, msg)
> +        rejected.append(f)
>
> +    m.bad = badfn
>      added, unknown, deleted, removed, forgotten = _interestingfiles(repo,
> m)
> +    m.bad = origbad
>

What happens if we don't reset it?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20141202/d01c5691/attachment.html>


More information about the Mercurial-devel mailing list