Re: .gitignore files, take two

On Tue, Sep 21, 2010 at 06:00, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Back here I asked what we were going to do about .gitignore files:
> http://archives.postgresql.org/pgsql-hackers/2010-08/msg01232.php
> The thread died off when the first git conversion attempt crashed and
> burned; but not before it became apparent that we didn't have much
> consensus.  It seemed that there was lack of agreement as to:
>
> 1. Whether to keep the per-subdirectory ignore files (which CVS
> insisted on, but git doesn't) or centralize in a single ignore file.

Both :-)

If there are wildcard ones to be made ("*.o" - though that one I
believe is excluded by default).

Direct build targets should go in a local one - alongside the Makefile
that builds them.

> 2. Whether to have the ignore files ignore common cruft such as
> editor backup files, or only "expected" build product files.

Editor backup files: no. That should be done locally, because everyone
has a different editor which may have different ideas about that.
Expected build product files: yes, because everybody gets those.

> Although this point wasn't really brought up during that thread, it's
> also the case that the existing implementation is far from consistent
> about ignoring build products.  We really only have .cvsignore entries
> for files that are not in CVS but are meant to be present in
> distribution tarballs.  CVS will, of its own accord, ignore certain
> build products such as .o files; but it doesn't ignore executables for
> instance.  So unless you do a "make distclean" before "cvs update",
> you will get notices about non-ignored files.  That never bothered me
> particularly but I believe it annoys some other folks.  So really there
> is a third area of disagreement:
>
> 3. What are the ignore filesets *for*, in particular should they list
> just the derived files expected in a distribution tarball, or all the
> files in the set of build products in a normal build?

I would like to see us exclude all build products. That'll make "git
status" a lot more useful (which it can be - whereas cvs status is
always annoying), particularly if you're working with multiple
branches and stashes and so.

I assume once we have a decision, we're backporting this to all active
branches, right?

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/