Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > On Thu, 15 Nov 2007, Bruce Stephens wrote: >> >> They are in the index. What I want is a list of files which are known >> to git, which are matched by the default rules (in particular the >> .gitignore files). > > Ahh. > > *All* the .gitignore rules are purely about files that git does not > already know about. Once git tracks a pathname, the ignore rules simply > do not matter. > > Files that are in the index are simply never ignored. There's no way to > ignore them, and in fact, the whole "git add -f" thing is a way to add > files to the index and override the exclude rules - at which point git > then tracks them regardless of any such exclude rules. OK. I think I sort of understood that, but it's nice to have it clearly stated. I'm not worried so much about files that already exist. I'm worried that we may in the future create files that we want to store in git and which are ignored. If we do that there's a chance we'll miss them (because "git gui", "git status", etc., won't bring attention to them). So it seemed valuable to try to make the .gitignore patterns precise: so that they ignore all the generated files that our builds produce, while not matching any files that git knows about. That certainly wouldn't guarantee that new files wouldn't be caught by the patterns, but it ought to lower the probability of this, since there's a decent chance that such files will either be not touched by the patterns (because they're *.java or something), or they'll fit into one of the already handled exceptions (Doxyfile.local is one: most *.local files are build products, but Doxyfile.local aren't). I guess if you're starting off with some project in git then this isn't such an issue: you evolve the patterns and the build process and so on in parallel. So maybe there's not such a demand for finding this information, and those of us who do want to do it are best using the "git add" loop approach? - 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
