Re: .gitignore files, take two

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: .gitignore files, take two
Date: 2010-09-21 11:12:06
Message-ID: AANLkTi=AgQFf1Kpt_Wg1_ropb-W1ckXbg-dBxLCD6Ldf@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Sep 21, 2010 at 1:06 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-09-21 11:55:27 Re: SHOW TABLES
Previous Message Robert Haas 2010-09-21 11:00:24 pgsql: git_topo_order script, to match up commits across branches.