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

Jeff King [off-list ref] writes:

On Sat, Feb 07, 2009 at 01:45:44PM -0800, Junio C Hamano wrote:

quoted

quoted

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."

On Sun, Feb 08, 2009 at 01:50:27AM -0800, Junio C Hamano wrote:

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: *~

Right, exactly. What I was trying to say in my original message was that
my toy implementation _didn't_ do that, and it is a downside.

-Peff