Re: .gitignore files, take two

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: .gitignore files, take two
Дата
Msg-id AANLkTi=AgQFf1Kpt_Wg1_ropb-W1ckXbg-dBxLCD6Ldf@mail.gmail.com
обсуждение исходный текст
Ответ на Re: .gitignore files, take two  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: .gitignore files, take two  (Magnus Hagander <magnus@hagander.net>)
Список pgsql-hackers
On Tue, Sep 21, 2010 at 1:06 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> I suppose you already know my votes, but here they are again just in case.
>> ...
>> Centralize.
>> ...
>> All the build products in a normal build.
>
> I don't understand your preference for this together with a centralized
> ignore file.  That will be completely unmaintainable IMNSHO.  A
> centralized file would work all right if it's limited to the couple
> dozen files that are currently listed in .cvsignore's, but I can't see
> doing it that way if it has to list every executable and .so built
> anywhere in the tree.  You'd get merge conflicts from
> completely-unrelated patches, not to mention the fundamental
> action-at-a-distance nastiness of a top-level file that knows about
> everything going on in every part of the tree.

Oh.  I was just figuring it would be pretty easy to regenerate from
the output of git status.  You might have merge conflicts but they'll
be trivial.  But then again, the effort of breaking up the output of
git status into individual per-directory files is probably largely a
one-time effort, so maybe it doesn't matter very much.

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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: Git conversion status
Следующее
От: Robert Haas
Дата:
Сообщение: Re: SHOW TABLES