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

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)
Дата
Msg-id 407d949e0908111710p460e15e6oac2d3b401261ee7f@mail.gmail.com
обсуждение исходный текст
Ответ на 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)  (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>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: "Hot standby"?
Следующее
От: Mike
Дата:
Сообщение: Re: Alpha 1 release notes