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