On Wed, Nov 25, 2015 at 11:49 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Euler Taveira <eu...@timbira.com.br> writes:
>> +1 to remove all of those files.
> Meh.  We've always shipped that stuff; before git, we shipped .cvsignore
> files, and there were no complaints about it, going back twenty years at
> this point.  If the files amounted to anything meaningful space-wise,
> I would agree, but as things stand I see no value in removing them.
> One plausible argument for them being useful to downstream users is that
> they provide positive documentation as to what derived files can be
> expected to appear while building the code.  (In this connection, I note
> that CVS didn't produce complaints about stray files, so that we had to
> work quite a bit on the ignore-files when we converted from CVS to git.
> That seems like useful value-added information.)
> I also have a personal reason for not removing them, which is that
> I usually verify built tarballs by diff'ing them against my local git
> checkout.  I do not need the noise of a bunch of "Only in ..." complaints
> from that.

Yeah, agreed.  If somebody gets them and doesn't want them, it's a
one-line find command to nuke them all.

find . -name .gitignore -exec rm {} \;

On the other hand, if we remove them, putting them back is not quite so trivial.

Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to