Re: .gitignore files, take two

On Tue, Sep 21, 2010 at 11:02 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
>> On tis, 2010-09-21 at 00:00 -0400, Tom Lane wrote:
>>> 3. What are the ignore filesets *for*, in particular should they list
>>> just the derived files expected in a distribution tarball, or all the
>>> files in the set of build products in a normal build?
>
>> My personal vote: Forget the whole thing.
>
> The folks who are more familiar with git than I seem to be pretty clear
> that we need to ignore all build products.  I don't think that "ignore
> nothing" is going to work pleasantly at all.  On reflection I realize
> that cvs ignore and git ignore are considerably different because they
> come into play at different times: cvs ignore really only matters while
> doing "cvs update" to pull in new code, while git ignore matters while
> you're constructing a commit.  So you really do need git ignore to
> ignore all build products; otherwise you'll have lots of chatter in
> "git status".

Back when I used CVS for anything, I used to use 'cvs -q update -d'
somewhat the way I now use 'git status', so I've always been in favor
of ignoring all the build products.  But it is true that you tend to
use 'git status' even a bit more, because you typically want to make
sure you've staged everything correctly before committing (unless, of
course, you always just do git commit -a, but that doesn't describe my
workflow very well).  At any rate, whatever the reasons, I'll be very,
very happy if we can settle on a rule to ignore all build products.
FWIW, "man gitignore" has these comments.

# A project normally includes such .gitignore files
# in its repository, containing patterns for files generated as part
# of the project build.

and further down:

# Patterns which a user wants git to
# ignore in all situations (e.g., backup or temporary files generated by
# the user's editor of choice) generally go into a file specified by
# core.excludesfile in the user's ~/.gitconfig.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company