.gitignore of tests

Edward Z. Yang ezyang at mit.edu
Tue Jul 29 10:09:14 UTC 2014

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?


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/767b9ddf7d2ea2bb99d49372c79be129fc2058ce
> 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

More information about the ghc-devs mailing list