Re: .gitignore files, take two - Mailing list pgsql-hackers

From Robert Haas
Subject Re: .gitignore files, take two
Date
Msg-id AANLkTi=AgQFf1Kpt_Wg1_ropb-W1ckXbg-dBxLCD6Ldf@mail.gmail.com
Whole thread Raw
In response to Re: .gitignore files, take two  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: .gitignore files, take two
List 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 by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Git conversion status
Next
From: Robert Haas
Date:
Subject: Re: SHOW TABLES