Jeff King <peff@xxxxxxxx> 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? -- 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
