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. For asking about one path, it may not be that big a deal to see that the output matches to the input. But if I feed a hundred paths to check-ignore, I expect to be able to scan the output for the input I put in. > 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 Yes, I would think so. Which maybe means using the current "exclude" code is not appropriate. Because it is really about traversing the directory structure, excluding as we go. I don't know that you can directly ask it about a particular path. -Peff -- 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
