Thread

.gitignore files, take two

Tom Lane <tgl@sss.pgh.pa.us> — 2010-09-21T04:00:39Z

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

Re: .gitignore files, take two

Robert Haas <robertmhaas@gmail.com> — 2010-09-21T04:55:53Z

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

Re: .gitignore files, take two

Tom Lane <tgl@sss.pgh.pa.us> — 2010-09-21T05:06:51Z

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

Re: .gitignore files, take two

Magnus Hagander <magnus@hagander.net> — 2010-09-21T07:00:28Z

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/

Re: .gitignore files, take two

Robert Haas <robertmhaas@gmail.com> — 2010-09-21T11:12:06Z

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

Re: .gitignore files, take two

Magnus Hagander <magnus@hagander.net> — 2010-09-21T12:12:33Z

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/

Re: .gitignore files, take two

Peter Eisentraut <peter_e@gmx.net> — 2010-09-21T14:27:59Z

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.

Re: .gitignore files, take two

Magnus Hagander <magnus@hagander.net> — 2010-09-21T14:31:31Z

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/

Re: .gitignore files, take two

Peter Eisentraut <peter_e@gmx.net> — 2010-09-21T14:38:05Z

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.

Re: .gitignore files, take two

Robert Haas <robertmhaas@gmail.com> — 2010-09-21T14:38:29Z

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

Re: .gitignore files, take two

Tom Lane <tgl@sss.pgh.pa.us> — 2010-09-21T15:02:30Z

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

Re: .gitignore files, take two

Robert Haas <robertmhaas@gmail.com> — 2010-09-21T15:12:55Z

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

Re: .gitignore files, take two

Peter Eisentraut <peter_e@gmx.net> — 2010-09-21T15:13:09Z

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.

Re: .gitignore files, take two

Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> — 2010-09-21T15:20:49Z

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

Re: .gitignore files, take two

Tom Lane <tgl@sss.pgh.pa.us> — 2010-09-21T15:27:38Z

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

Re: .gitignore files, take two

Andrew Dunstan <andrew@dunslane.net> — 2010-09-21T15:35:28Z


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

Re: .gitignore files, take two

Abhijit Menon-Sen <ams@toroid.org> — 2010-09-21T16:26:56Z

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

Re: .gitignore files, take two

Magnus Hagander <magnus@hagander.net> — 2010-09-21T17:18:20Z

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/

Re: .gitignore files, take two

Tom Lane <tgl@sss.pgh.pa.us> — 2010-09-21T17:46:33Z

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

Re: .gitignore files, take two

Magnus Hagander <magnus@hagander.net> — 2010-09-21T18:10:54Z

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/

Re: .gitignore files, take two

Peter Eisentraut <peter_e@gmx.net> — 2010-09-21T18:21:52Z

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.]+

Re: .gitignore files, take two

Tom Lane <tgl@sss.pgh.pa.us> — 2010-09-21T18:29:59Z

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

Re: .gitignore files, take two

Magnus Hagander <magnus@hagander.net> — 2010-09-21T18:35:55Z

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/

Re: .gitignore files, take two

Magnus Hagander <magnus@hagander.net> — 2010-09-21T18:46:28Z

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/

Re: .gitignore files, take two

Tom Lane <tgl@sss.pgh.pa.us> — 2010-09-21T18:59:00Z

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

Re: .gitignore files, take two

Magnus Hagander <magnus@hagander.net> — 2010-09-21T19:01:00Z

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/

Re: .gitignore files, take two

Tom Lane <tgl@sss.pgh.pa.us> — 2010-09-21T19:32:04Z

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

Re: .gitignore files, take two

Magnus Hagander <magnus@hagander.net> — 2010-09-21T19:43:22Z

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/

Re: .gitignore files, take two

Tom Lane <tgl@sss.pgh.pa.us> — 2010-09-21T20:06:48Z

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

Re: .gitignore files, take two

Andrew Dunstan <andrew@dunslane.net> — 2010-09-21T20:09:09Z


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

Re: .gitignore files, take two

Tom Lane <tgl@sss.pgh.pa.us> — 2010-09-21T20:11:50Z

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

Re: .gitignore files, take two

Magnus Hagander <magnus@hagander.net> — 2010-09-21T20:13:13Z

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/

Re: .gitignore files, take two

Tom Lane <tgl@sss.pgh.pa.us> — 2010-09-21T20:15:33Z

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

Re: .gitignore files, take two

Magnus Hagander <magnus@hagander.net> — 2010-09-21T20:17:57Z

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/

Re: .gitignore files, take two

Tom Lane <tgl@sss.pgh.pa.us> — 2010-09-21T20:23:45Z

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

Re: .gitignore files, take two

Magnus Hagander <magnus@hagander.net> — 2010-09-22T12:11:46Z

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/

Re: .gitignore files, take two

Kevin Grittner <kevin.grittner@wicourts.gov> — 2010-09-22T18:28:08Z

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

Re: .gitignore files, take two

Magnus Hagander <magnus@hagander.net> — 2010-09-22T18:32:55Z

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/

Re: .gitignore files, take two

Tom Lane <tgl@sss.pgh.pa.us> — 2010-09-22T18:38:10Z

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

Re: .gitignore files, take two

Magnus Hagander <magnus@hagander.net> — 2010-09-22T19:58:51Z

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/

Re: .gitignore files, take two

Kevin Grittner <kevin.grittner@wicourts.gov> — 2010-09-23T23:58:40Z

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

Re: .gitignore files, take two

Robert Haas <robertmhaas@gmail.com> — 2010-09-24T02:27:34Z

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

Re: .gitignore files, take two

James Cloos <cloos@jhcloos.com> — 2010-10-10T00:27:22Z

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

Re: .gitignore files, take two

Tom Lane <tgl@sss.pgh.pa.us> — 2010-10-10T04:42:06Z

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

Re: .gitignore files, take two

Gurjeet Singh <singh.gurjeet@gmail.com> — 2010-10-10T04:57:15Z

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.

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

Re: .gitignore files, take two

Robert Haas <robertmhaas@gmail.com> — 2010-10-10T21:33:25Z

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

Re: .gitignore files, take two

Florian Weimer <fweimer@bfk.de> — 2010-10-11T07:28:09Z

* 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