An hour ago, Johannes Sixt wrote: > Am 3/24/2011 11:10, schrieb Eli Barzilay: > > According to the man page, a .gitignore file that is deeper has > > higher precedence, and a `!' line overrides lower precedence > > ignores. I tried that, and it works in cases like the last > > "vmlinux*" example. > > > > But it doesn't work if the lower precedence directory has a "*" > > pattern. [...] > > > > Is this a bug? > > This has been discussed before, and IMNSHO, this is not a bug: > > http://thread.gmane.org/gmane.comp.version-control.git/157190 To reply to what you wrote there: > You should update your expectations to match what you got. That kind of an answer is a thick hint that something is not documented right. As things stand, I don't see anything in the man page that describes the actual algorithm that is used. I also found a similar weirdness now -- the man page says within one level of precedence, the last matching pattern decides the outcome but this is not true for nested files in this case: * !foo So some description of what's going on is needed. Perhaps it's exactly what Seth's suggested patch describes. In any case, it seems possible to do something that works more as expected. As suggested in that thread -- scanning only directories that have committed files would not make things slow, since the files need to be checked anyway. This is not even hard to describe in a man page. It seems like some arbitrariness that buys performance, but its less so than the current situation. There's also the option of scanning only .gitignore files that are checked in, but that will probably be too confusing when the files are created and/or modified. Yet another alternative is to say that an ignored .gitignore file is ignored, and making this: /* !.gitignore an idiom for doing the slow thing in case you really want it. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! -- 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