On Tue, Oct 27, 2009 at 11:03:28PM -0700, Junio C Hamano wrote: > 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? Happily, I did not remember how .cvsignore worked and had to go read the documentation. :) The answer is that no, it does not have the recursive feature in the root .cvsignore list at all. But it does apply the repo-wide CVSROOT/cvsignore, the user's ~/.cvsignore, and the environment's $CVSIGNORE to all directories. So it is safe from this problem (though now that I think on it, I think I was once bitten by something similar in the CVSROOT/cvsignore). SVN implements this with "properties" on the directories. They are not recursive at all. However, it also implements "global-ignores" which applies everywhere. So no, they don't have the same issue, because they explicitly split the "everywhere" and "this directory" cases into two locations. We wouldn't want to use .git/info/excludes for this, because we do want to support the project shipping some global excludes itself. > I am actually a bit reluctant to queue this, even though I most likely > will, and then hope that we will think of a better solution later, at > which time this file again needs to change. I am mixed on it, as well. I did see it bite someone, but I think it's very rare, and everyone who reads or touches the file will have to deal with the ugliness every time. If you want to drop the patch, I will not complain. > 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. That makes some sense to me (and in fact when making the patch, it was the rule of thumb I used). Though I think you might want to make it "starts with glob" as the trigger for the rule. We have "git-core-*/?*", which I would expect to still be anchored at the root. > 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. While clever, that use of '[d]' seems unneccessarily obscure to me. Why not just give a wildcard for "any subdirectory of me" and do: Makefile.depend **/Makefile.depend Since "**" is in common use in other systems, it's pretty clear (to me, anyway, but then I am the one suggesting the syntax ;) ) what that means. -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