[PATCH] add: only retrieve from dirstate.walk files that were not removed

[Matt Mackall]

On Tue, 2009-12-15 at 09:19 +0100, Benoit Boissinot wrote:
> On Mon, Dec 14, 2009 at 11:49:20AM -0600, Matt Mackall wrote:
> > On Mon, 2009-12-14 at 18:11 +0100, Benoit Boissinot wrote:
> > > On Mon, Dec 14, 2009 at 07:00:43PM +0900, Nicolas Dumazet wrote:
> > > > # HG changeset patch
> > > > # User Nicolas Dumazet <nicdumz.commits at gmail.com>
> > > > # Date 1260498662 -32400
> > > > # Node ID c13f2fd2afb5fb0c461ded5dbcd00cf9280d6ce9
> > > > # Parent  fd6729805f44c0686abf0a4d59449284b2ff7dd6
> > > > add: only retrieve from dirstate.walk files that were not removed
> > > > 
> > > > It does not make sense to match removed files in this context.
> > > > It should suppress a bogus hg add warning when adding a directory over
> > > > a removed file.
> > > 
> > > Sorry for the delay, I just had a look at this patch.
> > > 
> > > Isn't the real problem the use of m.exact()?
> > 
> > No. The problem is:
> > 
> > hg mv a b
> > mkdir a
> > touch a/a
> > hg add a  # should succeed
> > 
> > Because 'a' is in state 'removed', it gets returned by walk(), even
> > though it's not relevant.
> > 
> > >  Or that walk() should
> > > differentiate files that exists vs. file that existed (removed/missing).
> > 
> > No, compare:
> > 
> > rm a  # spurious unrecorded deletion of a
> > mkdir a
> > touch a/a
> > hg add a  # should complain loudly
> > 
> > walk() should definitely return a here as it is still relevant.
> 
> Is 'a' relevant?

I don't think it makes sense from an API perspective for walk() to
ignore missing files, even if we already happen to be doing the right
thing in localrepo.add(). Otherwise, we're fine-tuning the API to the
needs of commands.add(), which seems bogus.

I think we can do better though. The real complexity here (and several
other places) is making sure we do something on each exact pattern. It'd
be easier to filter out inappropriate matches if this was taken care of
for us. We should probably build something into match objects so that we
can more easily figure out which exact patterns didn't result in a
relevant match.

Also, it might be useful to extend include/exclude in match to allow
function filters. Then we could simply add "ignore all files marked 'r'
in dirstate" to the match object we build.

-- 
http://selenic.com : development and support for Mercurial and Linux