Junio C Hamano <gitster@xxxxxxxxx> writes: > Bruce Stephens <bruce.stephens@xxxxxxxxx> 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. - 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
