Re: [PATCH 2/2] give exclude mechanism a debug option

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> On Fri, Feb 06, 2009 at 11:38:38PM -0800, Junio C Hamano wrote:
>
>> >   2. If you ask for "foo/bar", and "foo/" is ignored, the
>> >      output will show only "foo: exclude: foo". This is an
>> >      artifact of the calling interface: you don't ask "is
>> >      foo/bar excluded", but rather while recursing through
>> >      "foo/" you ask "should I bother even recursing into
>> >      foo?". So the exclusion code never even knows that you
>> >      might have cared about foo/bar in the first place.
>> 
>> I do not see why it is a problem.  It exactly is what you want to know,
>> isn't it?
>
> Because I would expect "git check-ignore foo/bar | grep ^foo/bar:" to
> tell me if and how foo/bar is being excluded. But I have to instead
> check for ^foo and ^foo/bar.

Sorry, I do not understand why you need the downstream pipe that filters
using grep to begin with.

Shouldn't "git check-ignore dir/path" talk about the exclude entries that
caused dir/path to be excluded and no other patterns?  And if the reason
dir/path is exclude is because there was a higher level entry to exclude
dir/, the output would say so.  If there are unrelated exclude entries
that exclude dir's neighbour dir2 or dir/path's neighbour dir/path2, they
do not affect if dir/path is excluded, so check-ignore wouldn't show, no?