Re: Patch to .gitignore

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Patch to .gitignore
Дата
Msg-id 23775.1369400244@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Patch to .gitignore  (Fabrízio de Royes Mello <fabriziomello@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: German Becker
Дата:
Сообщение: Re: WAL segments (names) not in a sequence
Следующее
От: Amit Langote
Дата:
Сообщение: Re: WAL segments (names) not in a sequence