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

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 8, 2009, 09:50 UTC
Message-ID: <7vmycxz28s.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20090208085933.GB4392@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 12 quoted lines

> On Sat, Feb 07, 2009 at 01:45:44PM -0800, Junio C Hamano wrote:
>
>> > 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.
>
> Sorry, I should have been more clear. The grep was meant to simulate
> what my eyes and brain are doing. That is, if I ask "what are patterns
> affecting foo/bar?", I expect to see "foo/bar" in the output.

Oh, then the output format would, just like "grep" given more than one file tells which file it found the match in, talk about which path the output entry talks about when given more than one path.

Something like:

	$ git check-ignore foo/bar xyzzy~ hello.c
	foo/bar: foo/.gitignore:4: ??r
        xyzzy~: .git/info/excludes:22: *~

that says "foo/bar is ignored because line 4 of foo/.gitignore tells us to ignore any three-letter filename that ends with r, xyzzy~ is ignored because .git/info/excludes tells us to ignore everything that ends with tilde on line 22, and hello.c is not ignored at all."