ls-files -i: pay attention to exclusion of leading paths
authorJunio C Hamano <gitster@pobox.com>
Fri, 1 Jun 2012 18:28:00 +0000 (11:28 -0700)
committerJunio C Hamano <gitster@pobox.com>
Sun, 3 Jun 2012 23:05:42 +0000 (16:05 -0700)
commiteb41775ecc031cd8e38aebbd26826d74922a0db9
tree372293cf02d91d2cf953621d35b367c34b1c18a4
parentd9f5ef7a4a760d58f1f824f9fb8c12ef0371d3a9
ls-files -i: pay attention to exclusion of leading paths

"git ls-files --exclude=t/ -i" does not show paths in directory t/
that have been added to the index, but it should.

The excluded() API was designed for callers who walk the tree from
the top, checking each level of the directory hierarchy as it
descends if it is excluded, and not even bothering to recurse into
an excluded directory.  This would allow us optimize for a common
case by not having to check if the exclude pattern "foo/" matches
when looking at "foo/bar", because the caller should have noticed
that "foo" is excluded and did not even bother to read "foo/bar"
out of opendir()/readdir() to call it.

The code for "ls-files -i" however walks the index linearly, feeding
paths without checking if the leading directory is already excluded.

Introduce a helper function path_excluded() to let this caller
properly call excluded() check for higher hierarchies as necessary.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/ls-files.c
dir.c
dir.h