Re: 'git add' regression in git-1.7?

From: Jeff King <peff@peff.net>
Date: Mar 9, 2010, 22:37 UTC
Message-ID: <20100309223729.GA25265@sigill.intra.peff.net>
In-Reply-To: <7vhbp0ls26.fsf@alter.siamese.dyndns.org>

On Sun, Feb 28, 2010 at 06:00:17PM -0800, Junio C Hamano wrote:

Show 10 quoted lines

> Jeff King <peff@peff.net> writes:
> 
> > I'm not sure of the right way to fix this. We can drop further down into
> > the directory hierarchy when doing COLLECT_IGNORED and look for actual
> > files, but that may have a negative performance impact.
> 
> Wouldn't that have negative correctness impact?  I don't see an obvious
> way out, other than perhaps checking the set of pathspecs twice.  One
> thing that might help is to carry the seen[] array a bit longer so that we
> do not have to lose sight of what paths we were given but didn't match.

Sorry for the very late reply. Day-job has kept me busy.

No, we would still be correct if we recurse into the ignored directory _only_ to collect the ignored bits (so we don't even bother if COLLECT_IGNORED isn't set). But what I don't like is that you take a performance hit, because in most cases you won't ever care what's inside those directories. You need to recurse only when:

  - you actually care about all files. git-add does. git-status does not
    (unless you explicitly told it to show directories). So that would
    probably need a flag passed to fill_directory.

  - you have a pathspec that means the contents of the directory might
    be interesting. Right now we check in_pathspec in treat_one_path.
    But I think we would need to recognize that "subdir/file" is
    means "subdir" is in our pathspec (and that "sub*" means the same
    thing).

Your solution does something similar after the fact, but I am not 100% satisfied with it. I'll respond separately to that patch.

-Peff