| From: | Greg Stark <gsstark(at)mit(dot)edu> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY) |
| Date: | 2009-08-12 00:10:01 |
| Message-ID: | 407d949e0908111710p460e15e6oac2d3b401261ee7f@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers pgsql-hackers |
On Tue, Aug 11, 2009 at 4:56 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)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...
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2009-08-12 01:05:29 | Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY) |
| Previous Message | Bruce Momjian | 2009-08-11 23:14:45 | Re: Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY) |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mike | 2009-08-12 00:23:45 | Re: Alpha 1 release notes |
| Previous Message | Bruce Momjian | 2009-08-11 23:30:07 | Re: "Hot standby"? |