Re: Odd .gitignore behaviour

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 15, 2007, 22:13 UTC
Message-ID: <7vabpf40ow.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <7vir4341ok.fsf@gitster.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 12 quoted lines

> Bruce Stephens <bruce.stephens@isode.com> writes:
>
>> 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.