Thread: Additional git conversion steps
There are a couple of things I think should happen ASAP once the git
repository is up, but weren't mentioned in Magnus' plans:
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?
2. One thing I will miss from the removal of $PostgreSQL$ tags is that
they guaranteed that every file contained its own full pathname within
the source tree. I found myself using that an awful lot, mainly as a
source for copying-and-pasting file paths. To substitute for the tags,
I would like to propose a project standard that every file contain its
pathname in the header comment, not just the bare filename which is the
de facto standard at the moment. For example, instead of
/*-------------------------------------------------------------------------** plancache.c* Plan cache management.
we should have
/*-------------------------------------------------------------------------** src/backend/utils/cache/plancache.c*
Plancache management.
Whatever we do with the .cvsignore files will need to be back-patched
into all active branches, but I am not so anal-retentive as to wish
to back-patch the pathname comment changes.
Comments?
regards, tom lane
On Tue, Aug 17, 2010 at 2:21 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > There are a couple of things I think should happen ASAP once the git > repository is up, but weren't mentioned in Magnus' plans: > > 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. 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. > 2. One thing I will miss from the removal of $PostgreSQL$ tags is that > they guaranteed that every file contained its own full pathname within > the source tree. I found myself using that an awful lot, mainly as a > source for copying-and-pasting file paths. To substitute for the tags, > I would like to propose a project standard that every file contain its > pathname in the header comment, not just the bare filename which is the > de facto standard at the moment. For example, instead of This seems totally useless to me. However, I suppose you can do it if it makes you happy... > Whatever we do with the .cvsignore files will need to be back-patched > into all active branches, but I am not so anal-retentive as to wish > to back-patch the pathname comment changes. Yes, we should DEFINITELY back-patch the .cvsignore stuff. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
Tom Lane <tgl@sss.pgh.pa.us> wrote: > 1. The various .cvsignore files need to be replaced by .gitignore > files. I could post my .gitignore file if you like. I'm sure it can be improved upon by others, but it gives me a clean `git status` result when it should. Probably better than nothing as a start. > * src/backend/utils/cache/plancache.c > * Plan cache management. Sounds good to me. -Kevin
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
Tom Lane <tgl@sss.pgh.pa.us> wrote: > 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)? Yes. Just as a start, done on a rather ad hoc basis, mine is attached. If you put that at the top, current HEAD is clean, at least for the builds I do. -Kevin
Attachment
On 18 August 2010 04:42, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> 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. Things are subtly different with git. git will never "decide" to add a file to the index unless you explicitly tell it to, with `git add`. So the idea with a .gitignore file is to tune it so that when you type `git status` it only tells you about things that you might want to either a) commit, or b) clean up. With .rej files and other such items, it's nice that `git status` pipes up about them, because it reminds you to get rid of them when you're done hacking. > > 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)? You sure can! Cheers, BJ
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> I could post my .gitignore file if you like.
Yeah, let's see it.
regards, tom lane
On Tue, Aug 17, 2010 at 2:21 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > There are a couple of things I think should happen ASAP once the git > repository is up, but weren't mentioned in Magnus' plans: > > 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? Certainly, with two variations: 1. If you don't want to hear about *.rej or *.orig files, you could put relevant patterns into $GIT_DIR/.git/info/exclude That's not checked in - that's configuration for one particular repo, and that repo alone. 2. You can create a .gitignore file in any directory, and check it in; it'll indicate patterns to ignore in this directory and those below. So, you'd presumably do something like: echo "*.o" >> $GIT_DIR/.gitignore to deal with .o files echo "*~" >> $GIT_DIR/.gitignore so Emacs deteriorata gets ignored and some other set of additions for typical "cruft" that is normally safe to ignore. The existing .cvsignore files can simply get renamed to .gitignore, and that'll just work. I had the entertaining case where, with Slony-I, I did, within the same commit: git rm .cvsignore git add .gitignore (where I had copied data from one to the other) and discovered that Git discovered that this was actually a "mv" request. I frequently find myself doing a build of things, and then running: git status > .gitignore which stows *all* the generated files, commented, so that they aren't yet ignored. Then, edit .gitignore, stripping off leading # for things that should be ignored, and drop out anything that shouldn't be ignored. git commit .gitignore -m "Populate all generated files that should be ignored by Git" This is one of the first things worth committing once Git gets turned on. -- http://linuxfinances.info/info/linuxdistributions.html