On Sun, Feb 28, 2010 at 06:00:17PM -0800, Junio C Hamano wrote:
> Jeff King <peff@xxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html