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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)
Дата
Msg-id 2091.1250039129@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)  (Greg Stark <gsstark@mit.edu>)
Список pgsql-hackers
Greg Stark <gsstark@mit.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Alpha 1 release notes
Следующее
От: Tom Lane
Дата:
Сообщение: Re: WIP: getting rid of the pg_database flat file