Re: Odd .gitignore behaviour

Junio C Hamano [off-list ref] writes:

Bruce Stephens [off-list ref] writes:

quoted

So I think the output from git-ls-files is as expected (as I interpret
the manpage and your explanation).  So is git-add just using some
different code?

No, you found one of the longstanding bugs in dir.c:read_directory().

The funny thing is that I just sent out a message pointing out
bogus handling of per-directory exclude files in ls-files last
night.  Somehow people have a tendency to encounter the bugs in
the same vicinity independently.

By the way, about the problem I described briefly last night.

I never understood the intended use of -i option to ls-files,
but in your test repository (the one that has subsubdir), you
can do:

	$ git ls-files -i --exclude='a*'

to see "What paths have I already _staged_ that would have been
ignored if the exclude pattern were 'a*'".  You can abuse this
to list all the staged header files with:

	$ git ls-files -i --exclude='*.h'

but

	$ git ls-files -- '*.h'

is much simpler for that ;-).

In any case, it appears to me that the codepath used for that
"feature", and also the codepath used for -d (show deleted
files) and -m (show modified files) makes calls to excluded()
function to consult the exclusion mechanism without setting it
up properly, and I do not think

	$ git ls-files -i --exclude-per-directory=.gitignore

does what we would want.

The codepath for -o (show others) do use read_directory() which
sets up the exclusion mechanism with push/pop per-directory
exclude API, so that option should work.  But I suspect even it
did not work from a subdirectory because of the problem the
message I am responding to addresses.