Re: refining .gitignores

Linus Torvalds [off-list ref] writes:

On Thu, 15 Nov 2007, Bruce Stephens wrote:

quoted

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?