.gitignore files, take two
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.
2. Whether to have the ignore files ignore common cruft such as
editor backup files, or only "expected" build product files.
It was pointed out that exclusion rules could be configured locally
to one's own repository, so one possible answer to issue #2 is to
have only a minimal ignore-set embodied in .gitignore files, and let
people who prefer to ignore more stuff set that up in local preferences.
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?
We need to get some consensus on this now. Comments?
regards, tom lane
I suppose you already know my votes, but here they are again just in case.
On Tue, Sep 21, 2010 at 12:00 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
1. Whether to keep the per-subdirectory ignore files (which CVS
insisted on, but git doesn't) or centralize in a single ignore file.
Centralize.
2. Whether to have the ignore files ignore common cruft such as
editor backup files, or only "expected" build product files.
I don't care too much about this. A mild preference for just the
expected build product files, but then that's heavily influenced by my
choice of editor, which doesn't leave such cruft around permanently.
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?
All the build products in a normal build. One of the infelicities of
git is that 'git status' shows the untracked files at the bottom. So
if you have lots of unignored stuff floating around, the information
about which files you've actually changed or added to the index
scrolls right off the screen.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
Robert Haas <robertmhaas@gmail.com> writes:
I suppose you already know my votes, but here they are again just in case.
...
Centralize.
...
All the build products in a normal build.
I don't understand your preference for this together with a centralized
ignore file. That will be completely unmaintainable IMNSHO. A
centralized file would work all right if it's limited to the couple
dozen files that are currently listed in .cvsignore's, but I can't see
doing it that way if it has to list every executable and .so built
anywhere in the tree. You'd get merge conflicts from
completely-unrelated patches, not to mention the fundamental
action-at-a-distance nastiness of a top-level file that knows about
everything going on in every part of the tree.
To put it another way: would you expect anyone to take it seriously
if you proposed moving all the "make clean" rules into the top-level
Makefile? That's pretty much exactly what this would be.
regards, tom lane
On Tue, Sep 21, 2010 at 06:00, Tom Lane <tgl@sss.pgh.pa.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/
On Tue, Sep 21, 2010 at 1:06 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
I suppose you already know my votes, but here they are again just in case.
...
Centralize.
...
All the build products in a normal build.I don't understand your preference for this together with a centralized
ignore file. That will be completely unmaintainable IMNSHO. A
centralized file would work all right if it's limited to the couple
dozen files that are currently listed in .cvsignore's, but I can't see
doing it that way if it has to list every executable and .so built
anywhere in the tree. You'd get merge conflicts from
completely-unrelated patches, not to mention the fundamental
action-at-a-distance nastiness of a top-level file that knows about
everything going on in every part of the tree.
Oh. I was just figuring it would be pretty easy to regenerate from
the output of git status. You might have merge conflicts but they'll
be trivial. But then again, the effort of breaking up the output of
git status into individual per-directory files is probably largely a
one-time effort, so maybe it doesn't matter very much.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
On Tue, Sep 21, 2010 at 13:12, Robert Haas <robertmhaas@gmail.com> wrote:
On Tue, Sep 21, 2010 at 1:06 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
I suppose you already know my votes, but here they are again just in case.
...
Centralize.
...
All the build products in a normal build.I don't understand your preference for this together with a centralized
ignore file. That will be completely unmaintainable IMNSHO. A
centralized file would work all right if it's limited to the couple
dozen files that are currently listed in .cvsignore's, but I can't see
doing it that way if it has to list every executable and .so built
anywhere in the tree. You'd get merge conflicts from
completely-unrelated patches, not to mention the fundamental
action-at-a-distance nastiness of a top-level file that knows about
everything going on in every part of the tree.Oh. I was just figuring it would be pretty easy to regenerate from
the output of git status. You might have merge conflicts but they'll
be trivial. But then again, the effort of breaking up the output of
git status into individual per-directory files is probably largely a
one-time effort, so maybe it doesn't matter very much.
Breaking it up was quite trivial. Here's what I came up with after
building on my box. I'm sure there are some on other platforms showing
up, but this should be the majority.
I just realized it does not include contrib, but's that a mechanical
copy of the same thing.
So if we want to go with this way, i have the scripts/changes ready :)
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Attachments:
gitignore.patchapplication/octet-stream; name=gitignore.patchDownload+173-44
On tis, 2010-09-21 at 00:55 -0400, Robert Haas wrote:
One of the infelicities of
git is that 'git status' shows the untracked files at the bottom. So
if you have lots of unignored stuff floating around, the information
about which files you've actually changed or added to the index
scrolls right off the screen.
Perhaps you knew this, but 'git status -uno' is moderately useful
against that.
On Tue, Sep 21, 2010 at 16:27, Peter Eisentraut <peter_e@gmx.net> wrote:
On tis, 2010-09-21 at 00:55 -0400, Robert Haas wrote:
One of the infelicities of
git is that 'git status' shows the untracked files at the bottom. So
if you have lots of unignored stuff floating around, the information
about which files you've actually changed or added to the index
scrolls right off the screen.Perhaps you knew this, but 'git status -uno' is moderately useful
against that.
It is, but that one has the problem of not showing any untracked files
- so if you forgot to add a file/directory you *wanted* to be added,
it will also be hidden with -uno.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On tis, 2010-09-21 at 00:00 -0400, Tom Lane wrote:
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?
My personal vote: Forget the whole thing.
I have never found the .cvsignore files useful for anything, but they
have only been a small annoyance when someone else quietly updated them
when I supposedly forget. Some of the new proposed schemes
for .gitignore appear to be significantly more involved.
On Tue, Sep 21, 2010 at 8:12 AM, Magnus Hagander <magnus@hagander.net> wrote:
Breaking it up was quite trivial. Here's what I came up with after
building on my box. I'm sure there are some on other platforms showing
up, but this should be the majority.I just realized it does not include contrib, but's that a mechanical
copy of the same thing.So if we want to go with this way, i have the scripts/changes ready :)
Sounds good to me.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
Peter Eisentraut <peter_e@gmx.net> writes:
On tis, 2010-09-21 at 00:00 -0400, Tom Lane wrote:
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?
My personal vote: Forget the whole thing.
The folks who are more familiar with git than I seem to be pretty clear
that we need to ignore all build products. I don't think that "ignore
nothing" is going to work pleasantly at all. On reflection I realize
that cvs ignore and git ignore are considerably different because they
come into play at different times: cvs ignore really only matters while
doing "cvs update" to pull in new code, while git ignore matters while
you're constructing a commit. So you really do need git ignore to
ignore all build products; otherwise you'll have lots of chatter in
"git status".
regards, tom lane
On Tue, Sep 21, 2010 at 11:02 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Peter Eisentraut <peter_e@gmx.net> writes:
On tis, 2010-09-21 at 00:00 -0400, Tom Lane wrote:
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?My personal vote: Forget the whole thing.
The folks who are more familiar with git than I seem to be pretty clear
that we need to ignore all build products. I don't think that "ignore
nothing" is going to work pleasantly at all. On reflection I realize
that cvs ignore and git ignore are considerably different because they
come into play at different times: cvs ignore really only matters while
doing "cvs update" to pull in new code, while git ignore matters while
you're constructing a commit. So you really do need git ignore to
ignore all build products; otherwise you'll have lots of chatter in
"git status".
Back when I used CVS for anything, I used to use 'cvs -q update -d'
somewhat the way I now use 'git status', so I've always been in favor
of ignoring all the build products. But it is true that you tend to
use 'git status' even a bit more, because you typically want to make
sure you've staged everything correctly before committing (unless, of
course, you always just do git commit -a, but that doesn't describe my
workflow very well). At any rate, whatever the reasons, I'll be very,
very happy if we can settle on a rule to ignore all build products.
FWIW, "man gitignore" has these comments.
# A project normally includes such .gitignore files
# in its repository, containing patterns for files generated as part
# of the project build.
and further down:
# Patterns which a user wants git to
# ignore in all situations (e.g., backup or temporary files generated by
# the user's editor of choice) generally go into a file specified by
# core.excludesfile in the user's ~/.gitconfig.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
On tis, 2010-09-21 at 14:12 +0200, Magnus Hagander wrote:
Breaking it up was quite trivial. Here's what I came up with after
building on my box. I'm sure there are some on other platforms showing
up, but this should be the majority.
Note that shared library names are platform dependent.
On 21/09/10 18:02, Tom Lane wrote:
Peter Eisentraut<peter_e@gmx.net> writes:
On tis, 2010-09-21 at 00:00 -0400, Tom Lane wrote:
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?My personal vote: Forget the whole thing.
The folks who are more familiar with git than I seem to be pretty clear
that we need to ignore all build products. I don't think that "ignore
nothing" is going to work pleasantly at all. On reflection I realize
that cvs ignore and git ignore are considerably different because they
come into play at different times: cvs ignore really only matters while
doing "cvs update" to pull in new code, while git ignore matters while
you're constructing a commit. So you really do need git ignore to
ignore all build products; otherwise you'll have lots of chatter in
"git status".
Agreed. It's not a big deal though, until now I've just always used "git
status | less" and scrolled up to the beginning, ignoring the chatter.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Magnus Hagander <magnus@hagander.net> writes:
Breaking it up was quite trivial. Here's what I came up with after
building on my box. I'm sure there are some on other platforms showing
up, but this should be the majority.
I just realized it does not include contrib, but's that a mechanical
copy of the same thing.
So if we want to go with this way, i have the scripts/changes ready :)
This works for me, modulo some things:
If we are going to ignore *.so at the top level, we also need to ignore
*.sl (for HPUX) and *.dll (for Windows). I also wonder why we have
entries like this:
+libecpg.a
+libecpg.so.*
rather than global ignore patterns for *.a and *.so.[0-9]
We should probably ignore src/Makefile.custom, since that is still a
supported way to customize builds (and some of us still use it).
diff --git a/src/timezone/.gitignore b/src/timezone/.gitignore new file mode 100644 index 0000000..f844c9f --- /dev/null +++ b/src/timezone/.gitignore @@ -0,0 +1 @@ +/zic
Why does this entry have a / when none of the rest do? Shouldn't
we be consistent about that?
regards, tom lane
On 09/21/2010 11:20 AM, Heikki Linnakangas wrote:
On 21/09/10 18:02, Tom Lane wrote:
Peter Eisentraut<peter_e@gmx.net> writes:
On tis, 2010-09-21 at 00:00 -0400, Tom Lane wrote:
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?My personal vote: Forget the whole thing.
The folks who are more familiar with git than I seem to be pretty clear
that we need to ignore all build products. I don't think that "ignore
nothing" is going to work pleasantly at all. On reflection I realize
that cvs ignore and git ignore are considerably different because they
come into play at different times: cvs ignore really only matters while
doing "cvs update" to pull in new code, while git ignore matters while
you're constructing a commit. So you really do need git ignore to
ignore all build products; otherwise you'll have lots of chatter in
"git status".Agreed. It's not a big deal though, until now I've just always used
"git status | less" and scrolled up to the beginning, ignoring the
chatter.
FWIW, the buildfarm's git mode does not rely on ignore files any more,
unlike what we had for CVS. This came about after I followed up on a
suggestion Robert made at pgCon to use "git clean".
cheers
andrew
At 2010-09-21 11:02:30 -0400, tgl@sss.pgh.pa.us wrote:
So you really do need git ignore to ignore all build products;
otherwise you'll have lots of chatter in "git status".
Right.
I usually put build products into a top-level build directory and put
"build/" in my top-level .gitignore (but I haven't tried to figure out
how hard it would be to do that with the Postgres Makefiles, so it's
just a thought, not a serious suggestion).
-- ams
On Tue, Sep 21, 2010 at 17:27, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
Breaking it up was quite trivial. Here's what I came up with after
building on my box. I'm sure there are some on other platforms showing
up, but this should be the majority.I just realized it does not include contrib, but's that a mechanical
copy of the same thing.So if we want to go with this way, i have the scripts/changes ready :)
This works for me, modulo some things:
If we are going to ignore *.so at the top level, we also need to ignore
*.sl (for HPUX) and *.dll (for Windows). I also wonder why we have
*.sl was missing because I didn't know about it.
*.dll was missing because on msvc we always build out of tree. And I
forgot about mingw not doing that :-)
entries like this:
+libecpg.a
+libecpg.so.*rather than global ignore patterns for *.a and *.so.[0-9]
Yeah, that seems better.
We should probably ignore src/Makefile.custom, since that is still a
supported way to customize builds (and some of us still use it).
Ok, added.
diff --git a/src/timezone/.gitignore b/src/timezone/.gitignore new file mode 100644 index 0000000..f844c9f --- /dev/null +++ b/src/timezone/.gitignore @@ -0,0 +1 @@ +/zicWhy does this entry have a / when none of the rest do? Shouldn't
we be consistent about that?
We should. I've removed it.
The difference is that "zic" matches zic in any subdirectory and
"/zic" matches just in the top dir. But we're not having any other
thing called zic further down - it's really only a potential problem
at the top level.
How's this?
Btw, what's the "stamp-h" file? Should that be excluded globally?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Attachments:
gitignore.patchtext/x-patch; charset=US-ASCII; name=gitignore.patchDownload+207-44
Magnus Hagander <magnus@hagander.net> writes:
On Tue, Sep 21, 2010 at 17:27, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Why does this entry have a / when none of the rest do? �Shouldn't
we be consistent about that?
We should. I've removed it.
The difference is that "zic" matches zic in any subdirectory and
"/zic" matches just in the top dir. But we're not having any other
thing called zic further down - it's really only a potential problem
at the top level.
Hmm. In leaf subdirectories it doesn't matter of course, but I'm
worried about .gitignore files in non-leaf subdirectories accidentally
excluding files further down the tree. Wouldn't it be better to
standardize on always using the slash, rather than not using it?
Btw, what's the "stamp-h" file? Should that be excluded globally?
I'd say no, there's only one or two instances.
regards, tom lane
On Tue, Sep 21, 2010 at 19:46, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
On Tue, Sep 21, 2010 at 17:27, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Why does this entry have a / when none of the rest do? Shouldn't
we be consistent about that?We should. I've removed it.
The difference is that "zic" matches zic in any subdirectory and
"/zic" matches just in the top dir. But we're not having any other
thing called zic further down - it's really only a potential problem
at the top level.Hmm. In leaf subdirectories it doesn't matter of course, but I'm
worried about .gitignore files in non-leaf subdirectories accidentally
excluding files further down the tree. Wouldn't it be better to
standardize on always using the slash, rather than not using it?
Yeah, good point. I just took the path of least resistance :-) I'll
update with that before commit.
Have we decided to do this? If so, I'll start backpatching it...
Btw, what's the "stamp-h" file? Should that be excluded globally?
I'd say no, there's only one or two instances.
Ok. Since I don't know what it is, I didn't know if it's likely to pop
up anywhere else under different circumstances.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
