My 2 cents: I don't really care what we do, as long as (1) it's obvious where to put new gitignore entries, and (2) the gitignore list is accurate. Perhaps the testsuite should learn about Git and offer to add the files it creates to gitignore? Cheers, Edward Excerpts from Herbert Valerio Riedel's message of 2014-07-29 08:34:40 +0100:
Hello!
On 2014-07-29 at 08:25:15 +0200, Dr. ERDI Gergo wrote:
Is there a good reason we have a single monolithic .gitignore file in testuiste/ instead of one per directory? It just feels so unnecessarily burdensome to maintain it compared to just putting four lines in a new .gitignore file...
That's a good question I've been wondering about as well. I recently merged a few single .gitignore files I found in testsuite/ sub-folders into the main testsuite/.gitignore file it was rather inconsistent to have most stuff listed in the monolithic testsuite/.gitignore file and just a few deliberate .gitignores in a few sub-folders:
http://git.haskell.org/ghc.git/commitdiff/767b9ddf7d2ea2bb99d49372c79be129fc...
The other issue is tooling. Some Git front-ends such as http://magit.github.io/ don't even recognize non-top-level .gitignore files (yet), and certainly don't offer to create one if they don't find it in the current sub-folder (instead magit just adds it to the top-level gitignore file)
Also, I'm not sure if having .gitignore files sprinkled all over the source-tree instead of having just a few .gitignore files would be so much better, as in order to compute the "effective .gitignore", you have to consider the union of all existing .gitignore files up to the top-level folder (while not crossing Git repo boundaries).
However, we *can* switch to a scheme where we use many little per-folder .gitignore files, but everyone would have to agree to follow that new scheme, or we'll end up with a mess of confusing possibly overlapping .gitignore files.
Cheers, hvr