Skip site navigation (1) Skip section navigation (2)

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

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 (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-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...

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

In response to

Responses

pgsql-hackers by date

Next:From: MikeDate: 2009-08-12 00:23:45
Subject: Re: Alpha 1 release notes
Previous:From: Bruce MomjianDate: 2009-08-11 23:30:07
Subject: Re: "Hot standby"?

pgsql-committers by date

Next:From: Tom LaneDate: 2009-08-12 01:05:29
Subject: Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)
Previous:From: Bruce MomjianDate: 2009-08-11 23:14:45
Subject: Re: Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group