Re: .gitignore files, take two

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: .gitignore files, take two
Дата
Msg-id AANLkTimy1gSiGe-52bY47NF04ZV-hnr_sEz1aLj3AHdb@mail.gmail.com
обсуждение исходный текст
Ответ на Re: .gitignore files, take two  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: .gitignore files, take two  (Robert Haas <robertmhaas@gmail.com>)
Re: .gitignore files, take two  (Peter Eisentraut <peter_e@gmx.net>)
Re: .gitignore files, take two  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Tue, Sep 21, 2010 at 13:12, Robert Haas <robertmhaas@gmail.com> wrote:
> 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.

Breaking it up was quite trivial. Here's what I came up with after
building on my box. I'm sure there are some on other platforms showing
up, but this should be the majority.

I just realized it does not include contrib, but's that a mechanical
copy of the same thing.

So if we want to go with this way, i have the scripts/changes ready :)

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Вложения

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: SHOW TABLES
Следующее
От: Itagaki Takahiro
Дата:
Сообщение: Re: Basic JSON support