Re: Additional git conversion steps

On 18 August 2010 04:42, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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