Re: Patch to .gitignore - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Patch to .gitignore
Date
Msg-id 23775.1369400244@sss.pgh.pa.us
Whole thread Raw
In response to Re: Patch to .gitignore  (Fabrízio de Royes Mello <fabriziomello@gmail.com>)
List pgsql-hackers
Fabrízio de Royes Mello <fabriziomello@gmail.com> writes:
> On Fri, May 24, 2013 at 12:04 AM, Christopher Browne <cbbrowne@gmail.com>wrote:
>> There hasn't been general agreement on the merits of particular .gitignore
>> rules of this sort.

> I agree with you about vim-oriented patterns, because its a particular
> tool, but "ctags" and "etags" be part of postgres source tree and its
> generate some output inside them, so I think we must ignore it.

[ shrug... ]  Editor backup files get generated inside the source tree
as well.  Chris stated the policy accurately: if you use tools that
leave unexpected files in the source tree, it's up to you to have a
personal .gitignore for those, assuming you want them ignored.  The
project's .gitignore files are only supposed to list files that get
generated by the standard build processes.

FWIW, my personal .gitexclude file looks like

*~
*.orig

where the latter one is for junk generated by "patch".  I believe
patch's extension for saved files varies across versions, so it
wouldn't be too sensible to have an exclusion like that in the
project-wide file.  Note also that I intentionally *don't* have an
exclusion for *.rej --- if any patch hunk failed, I want git to
mention it.  But that's a matter of personal preference.  I rather
imagine that other people configure it differently, and that's fine.
As long as we don't try to put such things in the project-wide
exclusion list, we don't have to have a consensus about it.
        regards, tom lane



pgsql-hackers by date:

Previous
From: German Becker
Date:
Subject: Re: WAL segments (names) not in a sequence
Next
From: Amit Langote
Date:
Subject: Re: WAL segments (names) not in a sequence