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--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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.
--
Michael
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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, Suporte 24x7 e Treinamento
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers