| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Greg Stark <gsstark(at)mit(dot)edu> |
| 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 01:05:29 |
| Message-ID: | 2091.1250039129@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers pgsql-hackers |
Greg Stark <gsstark(at)mit(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2009-08-12 01:29:26 | Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY) |
| Previous Message | Greg Stark | 2009-08-12 00:10:01 | 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 | Tom Lane | 2009-08-12 01:10:06 | Re: WIP: getting rid of the pg_database flat file |
| Previous Message | Robert Haas | 2009-08-12 01:04:48 | Re: Alpha 1 release notes |