From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Additional git conversion steps |
Date: | 2010-08-17 18:42:25 |
Message-ID: | 20306.1282070545@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Aug 17, 2010 at 2:21 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Cédric Villemain | 2010-08-17 18:46:40 | Re: PL/pgSQL EXECUTE '..' USING with unknown |
Previous Message | Kevin Grittner | 2010-08-17 18:37:34 | Re: Additional git conversion steps |