Обсуждение: .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/
Вложения
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 @@ >> +/zic > > 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. 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/
Вложения
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/
On tis, 2010-09-21 at 11:27 -0400, Tom Lane wrote: > rather than global ignore patterns for *.a and *.so.[0-9] Probably rather *.so.[0-9.]+
Magnus Hagander <magnus@hagander.net> writes:
> Have we decided to do this? If so, I'll start backpatching it...
Yeah, go for it.
BTW, a look at the recommended GitExclude on the wiki suggests that
we need these two additional global exclusions:
*.mo ... for NLS builds*.dylib ... Darwin spelling of *.so
regards, tom lane
On Tue, Sep 21, 2010 at 20:21, Peter Eisentraut <peter_e@gmx.net> wrote: > On tis, 2010-09-21 at 11:27 -0400, Tom Lane wrote: >> rather than global ignore patterns for *.a and *.so.[0-9] > > Probably rather *.so.[0-9.]+ Any particular reason not to just do .so.*? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On Tue, Sep 21, 2010 at 20:29, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Magnus Hagander <magnus@hagander.net> writes: >> Have we decided to do this? If so, I'll start backpatching it... > > Yeah, go for it. > > BTW, a look at the recommended GitExclude on the wiki suggests that > we need these two additional global exclusions: > > *.mo ... for NLS builds > *.dylib ... Darwin spelling of *.so Added to list. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes:
> On Tue, Sep 21, 2010 at 20:21, Peter Eisentraut <peter_e@gmx.net> wrote:
>> On tis, 2010-09-21 at 11:27 -0400, Tom Lane wrote:
>>> rather than global ignore patterns for *.a and *.so.[0-9]
>>
>> Probably rather *.so.[0-9.]+
> Any particular reason not to just do .so.*?
Just paranoia, I guess. I can't actually see a reason why we'd have
any committable files in the tree matching that pattern. OTOH, we
probably also need the same type of pattern for .sl and .dylib,
so at some point a more conservative pattern would be wise.
regards, tom lane
On Tue, Sep 21, 2010 at 20:59, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Magnus Hagander <magnus@hagander.net> writes: >> On Tue, Sep 21, 2010 at 20:21, Peter Eisentraut <peter_e@gmx.net> wrote: >>> On tis, 2010-09-21 at 11:27 -0400, Tom Lane wrote: >>>> rather than global ignore patterns for *.a and *.so.[0-9] >>> >>> Probably rather *.so.[0-9.]+ > >> Any particular reason not to just do .so.*? > > Just paranoia, I guess. I can't actually see a reason why we'd have > any committable files in the tree matching that pattern. OTOH, we > probably also need the same type of pattern for .sl and .dylib, > so at some point a more conservative pattern would be wise. Do we know what the exact pattern would be for .sl and .dylib? Are they following the same basic pattern of .sl.<major>.<minor>? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes:
> On Tue, Sep 21, 2010 at 20:59, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Just paranoia, I guess. �I can't actually see a reason why we'd have
>> any committable files in the tree matching that pattern. �OTOH, we
>> probably also need the same type of pattern for .sl and .dylib,
>> so at some point a more conservative pattern would be wise.
> Do we know what the exact pattern would be for .sl and .dylib? Are
> they following the same basic pattern of .sl.<major>.<minor>?
Yes, they'll be just the same --- Makefile.shlib treats all those
extensions alike.
regards, tom lane
On Tue, Sep 21, 2010 at 21:32, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Magnus Hagander <magnus@hagander.net> writes: >> On Tue, Sep 21, 2010 at 20:59, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> Just paranoia, I guess. I can't actually see a reason why we'd have >>> any committable files in the tree matching that pattern. OTOH, we >>> probably also need the same type of pattern for .sl and .dylib, >>> so at some point a more conservative pattern would be wise. > >> Do we know what the exact pattern would be for .sl and .dylib? Are >> they following the same basic pattern of .sl.<major>.<minor>? > > Yes, they'll be just the same --- Makefile.shlib treats all those > extensions alike. Hmm. Hold on. My gitignore manpage doesn't say anything about supporting regular expressions at all. And actually adding the line proposed by Peter doesn't work. What works is adding all of: *.so *.so.[0-9] *.so.[0-9].[0-9] That will break if there's a two-digit number, i guess. Do we want to go with that anyway? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes:
> My gitignore manpage doesn't say anything about supporting regular
> expressions at all. And actually adding the line proposed by Peter
> doesn't work.
Yeah, I was wondering about that. They're meant to be shell patterns
not regexps, I think.
> What works is adding all of:
> *.so
> *.so.[0-9]
> *.so.[0-9].[0-9]
> That will break if there's a two-digit number, i guess. Do we want to
> go with that anyway?
What we can do, when and if any of those numbers get to two digits,
is add
*.so.[0-9][0-9]
etc etc. Which would not need to be back-patched. So let's just go in
that direction.
regards, tom lane
On 09/21/2010 03:43 PM, Magnus Hagander wrote: > > Hmm. Hold on. > > My gitignore manpage doesn't say anything about supporting regular > expressions at all. And actually adding the line proposed by Peter > doesn't work. > > What works is adding all of: > *.so > *.so.[0-9] > *.so.[0-9].[0-9] > > That will break if there's a two-digit number, i guess. Do we want to > go with that anyway? > They are shell globs. You could just add more patterns for the two digit cases if you care about it. It would be four more patterns for .so* cheers andrew
I wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> Do we know what the exact pattern would be for .sl and .dylib? Are
>> they following the same basic pattern of .sl.<major>.<minor>?
> Yes, they'll be just the same --- Makefile.shlib treats all those
> extensions alike.
I take that back. Darwin does things differently, bless their pointy
little heads:
DLSUFFIX = .dylib shlib = lib$(NAME).$(SO_MAJOR_VERSION).$(SO_MINOR_VERSION)$(DLSUFFIX)
So it looks like *.dylib is sufficient and we don't need anything with
numbers afterwards for that variant.
regards, tom lane
Magnus Hagander <magnus@hagander.net> writes:
> On Tue, Sep 21, 2010 at 22:11, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> So it looks like *.dylib is sufficient and we don't need anything with
>> numbers afterwards for that variant.
> Ok. Just to be clear, here's what I have now:
Global patterns look ok to me. Thought you were going to stick leading
slashes on all the others?
regards, tom lane
On Tue, Sep 21, 2010 at 22:15, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Magnus Hagander <magnus@hagander.net> writes: >> On Tue, Sep 21, 2010 at 22:11, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> So it looks like *.dylib is sufficient and we don't need anything with >>> numbers afterwards for that variant. > >> Ok. Just to be clear, here's what I have now: > > Global patterns look ok to me. Thought you were going to stick leading > slashes on all the others? Oh, misunderstood. I thought the idea was just slashes in the top-level ones, not the leaf ones. But I'll add it to those as well then :-) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes:
> On Tue, Sep 21, 2010 at 22:15, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Global patterns look ok to me. �Thought you were going to stick leading
>> slashes on all the others?
> Oh, misunderstood. I thought the idea was just slashes in the
> top-level ones, not the leaf ones. But I'll add it to those as well
> then :-)
I think it'd be wise to have a convention of leading slash anywhere
the pattern is not meant to be global. It won't matter to git in
leaf dirs, but it might prevent somebody from making a copy-and-paste
error later; or perhaps more likely, might prevent a problem if what
had been a leaf directory acquires children.
regards, tom lane
On Tue, Sep 21, 2010 at 22:23, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Magnus Hagander <magnus@hagander.net> writes: >> On Tue, Sep 21, 2010 at 22:15, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> Global patterns look ok to me. Thought you were going to stick leading >>> slashes on all the others? > >> Oh, misunderstood. I thought the idea was just slashes in the >> top-level ones, not the leaf ones. But I'll add it to those as well >> then :-) > > I think it'd be wise to have a convention of leading slash anywhere > the pattern is not meant to be global. It won't matter to git in > leaf dirs, but it might prevent somebody from making a copy-and-paste > error later; or perhaps more likely, might prevent a problem if what > had been a leaf directory acquires children. Done and applied. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> wrote: > Done and applied. I just did `make world`, `make check`, `sudo make install-world`, and `make installcheck-world`. I was left with these showing in my `git status`: # Untracked files: # (use "git add <file>..." to include in what will be committed) # # contrib/btree_gin/results/ # contrib/btree_gist/results/ # contrib/citext/results/ # contrib/cube/results/ # contrib/dblink/results/ # contrib/dict_int/results/ # contrib/dict_xsyn/results/ # contrib/earthdistance/results/ # contrib/hstore/results/ # contrib/intarray/results/ # contrib/ltree/results/ # contrib/pg_trgm/results/ # contrib/pgcrypto/results/ # contrib/seg/results/ # contrib/tablefunc/results/ # contrib/test_parser/results/ # contrib/tsearch2/results/ # contrib/unaccent/results/ # contrib/xml2/pgxml.sql # contrib/xml2/results/ # doc/src/sgml/HTML.index # doc/src/sgml/bookindex.sgml # doc/src/sgml/postgres.xml # src/interfaces/ecpg/test/compat_informix/charfuncs # src/interfaces/ecpg/test/compat_informix/charfuncs.c # src/interfaces/ecpg/test/compat_informix/dec_test # src/interfaces/ecpg/test/compat_informix/dec_test.c # src/interfaces/ecpg/test/compat_informix/describe # src/interfaces/ecpg/test/compat_informix/describe.c # src/interfaces/ecpg/test/compat_informix/rfmtdate # src/interfaces/ecpg/test/compat_informix/rfmtdate.c # src/interfaces/ecpg/test/compat_informix/rfmtlong # src/interfaces/ecpg/test/compat_informix/rfmtlong.c # src/interfaces/ecpg/test/compat_informix/rnull # src/interfaces/ecpg/test/compat_informix/rnull.c # src/interfaces/ecpg/test/compat_informix/sqlda # src/interfaces/ecpg/test/compat_informix/sqlda.c # src/interfaces/ecpg/test/compat_informix/test_informix # src/interfaces/ecpg/test/compat_informix/test_informix.c # src/interfaces/ecpg/test/compat_informix/test_informix2 # src/interfaces/ecpg/test/compat_informix/test_informix2.c # src/interfaces/ecpg/test/connect/test1 # src/interfaces/ecpg/test/connect/test1.c # src/interfaces/ecpg/test/connect/test2 # src/interfaces/ecpg/test/connect/test2.c # src/interfaces/ecpg/test/connect/test3 # src/interfaces/ecpg/test/connect/test3.c # src/interfaces/ecpg/test/connect/test4 # src/interfaces/ecpg/test/connect/test4.c # src/interfaces/ecpg/test/connect/test5 # src/interfaces/ecpg/test/connect/test5.c # src/interfaces/ecpg/test/pg_regress # src/interfaces/ecpg/test/pgtypeslib/dt_test # src/interfaces/ecpg/test/pgtypeslib/dt_test.c # src/interfaces/ecpg/test/pgtypeslib/dt_test2 # src/interfaces/ecpg/test/pgtypeslib/dt_test2.c # src/interfaces/ecpg/test/pgtypeslib/nan_test # src/interfaces/ecpg/test/pgtypeslib/nan_test.c # src/interfaces/ecpg/test/pgtypeslib/num_test # src/interfaces/ecpg/test/pgtypeslib/num_test.c # src/interfaces/ecpg/test/pgtypeslib/num_test2 # src/interfaces/ecpg/test/pgtypeslib/num_test2.c # src/interfaces/ecpg/test/preproc/array_of_struct # src/interfaces/ecpg/test/preproc/array_of_struct.c # src/interfaces/ecpg/test/preproc/autoprep # src/interfaces/ecpg/test/preproc/autoprep.c # src/interfaces/ecpg/test/preproc/comment # src/interfaces/ecpg/test/preproc/comment.c # src/interfaces/ecpg/test/preproc/cursor # src/interfaces/ecpg/test/preproc/cursor.c # src/interfaces/ecpg/test/preproc/define # src/interfaces/ecpg/test/preproc/define.c # src/interfaces/ecpg/test/preproc/init # src/interfaces/ecpg/test/preproc/init.c # src/interfaces/ecpg/test/preproc/outofscope # src/interfaces/ecpg/test/preproc/outofscope.c # src/interfaces/ecpg/test/preproc/strings # src/interfaces/ecpg/test/preproc/strings.c # src/interfaces/ecpg/test/preproc/type # src/interfaces/ecpg/test/preproc/type.c # src/interfaces/ecpg/test/preproc/variable # src/interfaces/ecpg/test/preproc/variable.c # src/interfaces/ecpg/test/preproc/whenever # src/interfaces/ecpg/test/preproc/whenever.c # src/interfaces/ecpg/test/results/ # src/interfaces/ecpg/test/sql/array # src/interfaces/ecpg/test/sql/array.c # src/interfaces/ecpg/test/sql/binary # src/interfaces/ecpg/test/sql/binary.c # src/interfaces/ecpg/test/sql/code100 # src/interfaces/ecpg/test/sql/code100.c # src/interfaces/ecpg/test/sql/copystdout # src/interfaces/ecpg/test/sql/copystdout.c # src/interfaces/ecpg/test/sql/define # src/interfaces/ecpg/test/sql/define.c # src/interfaces/ecpg/test/sql/desc # src/interfaces/ecpg/test/sql/desc.c # src/interfaces/ecpg/test/sql/describe # src/interfaces/ecpg/test/sql/describe.c # src/interfaces/ecpg/test/sql/dynalloc # src/interfaces/ecpg/test/sql/dynalloc.c # src/interfaces/ecpg/test/sql/dynalloc2 # src/interfaces/ecpg/test/sql/dynalloc2.c # src/interfaces/ecpg/test/sql/dyntest # src/interfaces/ecpg/test/sql/dyntest.c # src/interfaces/ecpg/test/sql/execute # src/interfaces/ecpg/test/sql/execute.c # src/interfaces/ecpg/test/sql/fetch # src/interfaces/ecpg/test/sql/fetch.c # src/interfaces/ecpg/test/sql/func # src/interfaces/ecpg/test/sql/func.c # src/interfaces/ecpg/test/sql/indicators # src/interfaces/ecpg/test/sql/indicators.c # src/interfaces/ecpg/test/sql/insupd # src/interfaces/ecpg/test/sql/insupd.c # src/interfaces/ecpg/test/sql/oldexec # src/interfaces/ecpg/test/sql/oldexec.c # src/interfaces/ecpg/test/sql/parser # src/interfaces/ecpg/test/sql/parser.c # src/interfaces/ecpg/test/sql/quote # src/interfaces/ecpg/test/sql/quote.c # src/interfaces/ecpg/test/sql/show # src/interfaces/ecpg/test/sql/show.c # src/interfaces/ecpg/test/sql/sqlda # src/interfaces/ecpg/test/sql/sqlda.c # src/interfaces/ecpg/test/thread/alloc # src/interfaces/ecpg/test/thread/alloc.c # src/interfaces/ecpg/test/thread/descriptor # src/interfaces/ecpg/test/thread/descriptor.c # src/interfaces/ecpg/test/thread/prep # src/interfaces/ecpg/test/thread/prep.c # src/interfaces/ecpg/test/thread/thread # src/interfaces/ecpg/test/thread/thread.c # src/interfaces/ecpg/test/thread/thread_implicit # src/interfaces/ecpg/test/thread/thread_implicit.c -Kevin
On Wed, Sep 22, 2010 at 20:28, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote: > Magnus Hagander <magnus@hagander.net> wrote: > >> Done and applied. > > I just did `make world`, `make check`, `sudo make install-world`, and > `make installcheck-world`. I was left with these showing in my `git > status`: Ahh. Clearly I didn't run the regression tests for contrib and ecpg. I'll take a look at that. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes:
> On Wed, Sep 22, 2010 at 20:28, Kevin Grittner
> <Kevin.Grittner@wicourts.gov> wrote:
>> Magnus Hagander <magnus@hagander.net> wrote:
>>
> Done and applied.
>>
>> I just did `make world`, `make check`, `sudo make install-world`, and
>> `make installcheck-world`. �I was left with these showing in my `git
>> status`:
> Ahh. Clearly I didn't run the regression tests for contrib and ecpg.
> I'll take a look at that.
I'm on it already for contrib and the PLs. But if you wanna do ecpg,
that'd be helpful, because I forgot about that ...
regards, tom lane
On Wed, Sep 22, 2010 at 20:38, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Magnus Hagander <magnus@hagander.net> writes: >> On Wed, Sep 22, 2010 at 20:28, Kevin Grittner >> <Kevin.Grittner@wicourts.gov> wrote: >>> Magnus Hagander <magnus@hagander.net> wrote: >>> >> Done and applied. >>> >>> I just did `make world`, `make check`, `sudo make install-world`, and >>> `make installcheck-world`. I was left with these showing in my `git >>> status`: > >> Ahh. Clearly I didn't run the regression tests for contrib and ecpg. > >> I'll take a look at that. > > I'm on it already for contrib and the PLs. But if you wanna do ecpg, > that'd be helpful, because I forgot about that ... Done. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On Tue, Sep 21, 2010 at 22:11, Tom Lane <tgl@sss.pgh.pa.us> wrote: > I wrote: >> Magnus Hagander <magnus@hagander.net> writes: >>> Do we know what the exact pattern would be for .sl and .dylib? Are >>> they following the same basic pattern of .sl.<major>.<minor>? > >> Yes, they'll be just the same --- Makefile.shlib treats all those >> extensions alike. > > I take that back. Darwin does things differently, bless their pointy > little heads: > > DLSUFFIX = .dylib > shlib = lib$(NAME).$(SO_MAJOR_VERSION).$(SO_MINOR_VERSION)$(DLSUFFIX) > > So it looks like *.dylib is sufficient and we don't need anything with > numbers afterwards for that variant. Ok. Just to be clear, here's what I have now: -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Вложения
Magnus Hagander <magnus@hagander.net> wrote: > Ok. Just to be clear, here's what I have now Here's one I found that got missed. (Perhaps you need to configure --with-libxml to get it.) -Kevin
Вложения
On Thu, Sep 23, 2010 at 7:58 PM, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote: > Magnus Hagander <magnus@hagander.net> wrote: > >> Ok. Just to be clear, here's what I have now > > Here's one I found that got missed. (Perhaps you need to configure > --with-libxml to get it.) Looks like it. Committed and back-patched to 8.0. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
I'm reading this a bit late, but... We (Xorg) found that ignoring: *~ *.bak *.patch in addition to the files generated by building is very helpful. We do use git tag and git describe in the make dist process, as well as git log >ChangeLog. That may be relevant; avoiding git describe's dirty designation is important when using it in that fashion. But it helps to be able to run git add --all cleanly. I understand that other git users have similar experience. -JimC -- James Cloos <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6
James Cloos <cloos@jhcloos.com> writes:
> I'm reading this a bit late, but...
> We (Xorg) found that ignoring:
> *~
> *.bak
> *.patch
> in addition to the files generated by building is very helpful.
Yeah ... personally I'm ignoring *~ and *.orig. I think that the
consensus among pgsql-hackers was that these sorts of things are
dependent on one's personal work habits, choice of editor and patch
tool, etc. So we're not ignoring them in the common project .gitignore
files, but it's easy enough to install them in a private ignore file.
regards, tom lane
On Tue, Sep 21, 2010 at 12:55 AM, Robert Haas <robertmhaas@gmail.com> wrote:
I have just started to read the thread, so don't know if somebody already chimed in.
You can avoid the above situation by adding the folowing to ~/.gitconfig or .git/config
[pager]
status = true
I think I used `git config` command for this, but adding by hand would also do.
Regards,
-- 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.
I have just started to read the thread, so don't know if somebody already chimed in.
You can avoid the above situation by adding the folowing to ~/.gitconfig or .git/config
[pager]
status = true
I think I used `git config` command for this, but adding by hand would also do.
Regards,
gurjeet.singh
@ EnterpriseDB - The Enterprise Postgres Company
http://www.EnterpriseDB.com
singh.gurjeet@{ gmail | yahoo }.com
Twitter/Skype: singh_gurjeet
Mail sent from my BlackLaptop device
On Oct 10, 2010, at 12:57 AM, Gurjeet Singh <singh.gurjeet@gmail.com> wrote:
On Tue, Sep 21, 2010 at 12:55 AM, Robert Haas <robertmhaas@gmail.com> wrote: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.
I have just started to read the thread, so don't know if somebody already chimed in.
You can avoid the above situation by adding the folowing to ~/.gitconfig or .git/config
[pager]
status = true
I think I used `git config` command for this, but adding by hand would also do.
Oh, dude. Awesome.
...Robert
* James Cloos: > I'm reading this a bit late, but... > > We (Xorg) found that ignoring: > > *~ > *.bak > *.patch > > in addition to the files generated by building is very helpful. I tend to put those into .git/info/exclude. They are somewhat developer-specific, after all. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99