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:
http://www.postgresql.org/mailpref/pgsql-hackers
