On 18 August 2010 04:42, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
