Re: Additional git conversion steps - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Additional git conversion steps
Date
Msg-id 20306.1282070545@sss.pgh.pa.us
Whole thread Raw
In response to Re: Additional git conversion steps  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Additional git conversion steps  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Re: Additional git conversion steps  (Brendan Jurd <direvus@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Aug 17, 2010 at 2:21 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 1. The various .cvsignore files need to be replaced by .gitignore files.
>> I am not sure though whether this is a trivial conversion --- does git
>> have similar default rules about ignoring .o, etc?

> No, it doesn't.  There are some policy decisions to be made here, too,
> about what we wish to actually ignore.  Personally, my preference
> would be to arrange to ignore all and only *build products*, but not
> things like *.rej files that CVS "helpfully" fails to mention.

My understanding of the point of an ignore file is to make sure that the
SCM doesn't decide to commit junk into the repository.  So *.rej, and
editor backup files (*~) should be in the ignore files IMO.  I'm not
totally clear on what CVS' default list is, though.

> Also,
> I think we should consider having just one .gitignore file at the top
> level rather than a file in every individual directory (you can
> include relative pathnames).  I think that might be significantly
> easier to manage.

Well, the per-directory files are that way because CVS insists, but
we could certainly consider alternative layouts if git can do better.
I'm not convinced that one big file is better though.  Can we use a
single file at the top level for policy (*.o, *.so, etc) and additional
files lower down for specific exceptions (parser/gram.c)?
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: Additional git conversion steps
Next
From: Cédric Villemain
Date:
Subject: Re: PL/pgSQL EXECUTE '..' USING with unknown