Thread: What .gitignore files do in the tarball?

Collegues,

I've noticed that source distribution archive of the postgresql contain
more than hundred of .gitignore files and one .gitattributes.

Is it just a bug nobody bothered to fix, or these files can make
any sense outside git repository?

Fix of the problem is quite trivial:

diff --git a/GNUmakefile.in b/GNUmakefile.in
index 15fba9f..beef51a 100644
--- a/GNUmakefile.in
+++ b/GNUmakefile.in
@@ -93,7 +93,7 @@ distdir-location:distdir:       rm -rf $(distdir)* $(dummy)
-       for x in `cd $(top_srcdir) && find . \( -name CVS -prune \) -o
\( -name .git -prune \) -o -print`; do \
+       for x in `cd $(top_srcdir) && find . \( -name CVS -prune \) -o
\( -name .git -prune \) -o \( \! -name ".git*" -print \)`; do \
file=`expr X$$x : 'X\./\(.*\)'`; \ if test -d "$(top_srcdir)/$$file" ;
then \ mkdir "$(distdir)/$$file" && chmod 777 "$(distdir)/$$file"; \
--                                                          Victor Wagner

Victor Wagner wrote:
> Collegues,
> 
> I've noticed that source distribution archive of the postgresql contain
> more than hundred of .gitignore files and one .gitattributes.
> 
> Is it just a bug nobody bothered to fix, or these files can make
> any sense outside git repository?

I agree they are pointless, let's get rid of them.


-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On Wed, Nov 25, 2015 at 8:40 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Wed, Nov 25, 2015 at 4:36 PM, Victor Wagner <vitus@wagner.pp.ru> wrote:
>> I've noticed that source distribution archive of the postgresql contain
>> more than hundred of .gitignore files and one .gitattributes.
>>
>> Is it just a bug nobody bothered to fix, or these files can make
>> any sense outside git repository?
>
> They are harmless and do not consume that much space in a tarball, contrary
> to .git/ which has the whole history of the repository. And this behavior
> matches for example git-archive. Keeping them also has the advantage to
> allow people to deploy a tarball easily in an orphan branch of a fresh git
> repository. In a couple of companies where people can just work from
> tarballs (this exists and I know some), that's actually useful to keep them.

+1.  I see 113 files totaling 8266 bytes.  That's not much, and like
you say, they might be useful to somebody.

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

On 25-11-2015 10:40, Michael Paquier wrote:
> 
> 
> On Wed, Nov 25, 2015 at 4:36 PM, Victor Wagner <vitus@wagner.pp.ru
> <mailto:vitus@wagner.pp.ru>> wrote:
> 
>     I've noticed that source distribution archive of the postgresql contain
>     more than hundred of .gitignore files and one .gitattributes.
> 
>     Is it just a bug nobody bothered to fix, or these files can make
>     any sense outside git repository?
> 
> 
> They are harmless and do not consume that much space in a tarball,
> contrary to .git/ which has the whole history of the repository. And
> this behavior matches for example git-archive. Keeping them also has the
> advantage to allow people to deploy a tarball easily in an orphan branch
> of a fresh git repository. In a couple of companies where people can
> just work from tarballs (this exists and I know some), that's actually
> useful to keep them.
>
Even if they are small, git use will be limited without .git directory.
The weird setup you mentioned above could be used but imho it is rare.
People who want to work on tarballs are not interested in repository
history or which file belongs to repository. If someone wants to develop
a patch, we should advice him/her to use git.

+1 to remove all of those files.


--   Euler Taveira                   Timbira - http://www.timbira.com.br/  PostgreSQL: Consultoria, Desenvolvimento,
Suporte24x7 e Treinamento
 

Euler Taveira <euler@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.
        regards, tom lane

On Wed, Nov 25, 2015 at 11:49 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Euler Taveira <euler@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