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 Greg Stark
Subject Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)
Date
Msg-id 407d949e0908111710p460e15e6oac2d3b401261ee7f@mail.gmail.com
Whole thread Raw
In response to pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Tue, Aug 11, 2009 at 4:56 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> A more aggressive approach would be to run pgindent immediately after
> the close of *each* commitfest, but that would tend to break patches
> that had gotten punted to the next fest.


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.
If just one patch was committed they would have to resolve the
conflicts in their subsequent patches before resubmitting. Of course
in all likelihood tom would have rewritten their first patch
anyways...

-- 
greg
http://mit.edu/~gsstark/resume.pdf


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: "Hot standby"?
Next
From: Mike
Date:
Subject: Re: Alpha 1 release notes