Junio C Hamano schrieb: > How does .cvsignore and .svnignore work? Don't they have the same issue, > and perhaps worse as I do not recall seeing a way to anchor a pattern to a > particular directory like we do in their .SCMignore files? And judging > from the fact that they can get away with the lack of that "feature", this > perhaps is not an issue in real life? .cvsignore and .svnignore do not apply recursively to subdirectories, do they? > For example, it crossed my mind that perhaps we can change the ignore > rules so that a non-globbing pattern is automatically anchored at the > current directly but globbing ones are recursive as before. > > If we do so, there is no need to change the current .gitignore entires. > You need to spell a concrete filename as a glob pattern that matches only > one path if you want the recursive behaviour. E.g. if you have a Makefile > per subdirectory, each of which generates and includes Makefile.depend > file, you would write "Makefile.depen[d]" in the toplevel .gitignore file. In one project that uses autotools, I have "Makefile" and "Makefile.in" in the top-level .gitignore. I would be forced to use this ugliness instead. Granted, to write "/git", "/git-add", etc in .gitignore is not exactly pretty, either, but the reason that it is so extra-ugly in the git code itself is only because there are so many build products in a single directory that cannot be caught by a glob pattern. In practice, you usually have only a hand-full non-glob ignored files per directory; it doesn't hurt to anchor them using "/frotz" style. > But that is a kind of incompatible change whose necessity is unproven and > has to cook and wait. I would be concerned by this change. -- Hannes -- 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