Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)
Date
Msg-id 2091.1250039129@sss.pgh.pa.us
Whole thread Raw
In response to Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
Greg Stark <gsstark@mit.edu> writes:
> What would happen if we ran pgindent immediately after every commit?
> So nobody would ever see a checkout that wasn't pgindent-clean?

> The only losers I see would be people working on multi-part patches.

... which we're trying to encourage ...

Actually, the case that started this thread is relevant: a forced
reindent would be *more* likely to have broken other patches than
not doing one.  I don't really like removing human judgment from
the process.

It definitely would help if large sections of new code were properly
indented before they got committed (assuming there are not followup
patches already prepared).  In the case of modifications to existing
code, the question is not nearly so black-and-white.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Alpha 1 release notes
Next
From: Tom Lane
Date:
Subject: Re: WIP: getting rid of the pg_database flat file