Re: run pgindent on a regular basis / scripted manner

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: run pgindent on a regular basis / scripted manner
Дата
Msg-id CAApHDvqz04z2kBubY5xHZ2UkcGBMzV5eT-sMAkHjeNVYPSSdzQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: run pgindent on a regular basis / scripted manner  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: run pgindent on a regular basis / scripted manner  (Peter Eisentraut <peter@eisentraut.org>)
Re: run pgindent on a regular basis / scripted manner  (Jelte Fennema <postgres@jeltef.nl>)
Список pgsql-hackers
On Wed, 18 Oct 2023 at 01:47, Robert Haas <robertmhaas@gmail.com> wrote:
> On Sat, Aug 12, 2023 at 5:53 PM Peter Geoghegan <pg@bowt.ie> wrote:
> > This policy isn't working.
>
> +1. I think this is more annoying than the status quo ante.

Maybe there are two camps of committers here; ones who care about
committing correctly indented code and ones who do not.

I don't mean that in a bad way, but if a committer just does not care
about correctly pgindented code then he/she likely didn't suffer
enough pain from how things used to be... having to unindent all the
unrelated indent fixes that were committed since the last pgindent run
I personally found slow/annoying/error-prone.

What I do now seems significantly easier. Assuming it's just 1 commit, just:

perl src/tools/pgindent/pgindent --commit HEAD
git diff # manual check to see if everything looks sane.
git commit -a --fixup HEAD
git rebase -i HEAD~2

If we were to go back to how it was before, then why should I go to
the trouble of unindenting all the unrelated indents from code changed
by other committers since the last pgindent run when those committers
are not bothering to and making my job harder each time they commit
incorrectly indented code.

How many of the committers who have broken koel are repeat offenders?
What is their opinion on this?
Did they just forget once or do they hate the process and want to go back?

I'm personally very grateful for all the work that was done to improve
pgindent and set out the new process. I'd really rather not go back to
how things were.

I agree that it's not nice to add yet another way of breaking the
buildfarm and even more so when the committer did make check-world
before committing. We have --enable-tap-tests, we could have
--enable-indent-checks and have pgindent check the code is correctly
indented during make check-world. Then just not have
--enable-indent-checks in CI.

I think many of us have scripts we use instead of typing out all the
configure options we want.  It's likely pretty easy to add
--enable-indent-checks to those.

David



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Some performance degradation in REL_16 vs REL_15
Следующее
От: shveta malik
Дата:
Сообщение: Re: Synchronizing slots from primary to standby