Re: run pgindent on a regular basis / scripted manner

On 2023-10-17 Tu 09:52, Robert Haas wrote:
> On Tue, Oct 17, 2023 at 6:34 AM Jelte Fennema <postgres@jeltef.nl> wrote:
>> I think *it is* dead easy to comply. If you run the following commands
>> before committing/after rebasing, then koel should always be happy:
>>
>> src/tools/pgindent/pgindent src # works always but a bit slow
>> src/tools/pgindent/pgindent $(git diff --name-only --diff-filter=ACMR)
>> # much faster, but only works if you DID NOT change typedefs.list
> In isolation, that's true, but the list of mistakes that you can make
> while committing which will inconvenience everyone working on the
> project is very long. Another one that comes up frequently is
> forgetting to bump CATALOG_VERSION_NO, but you also need a good commit
> message, and good comments, and a good Discussion link in the commit
> message, and the right list of authors and reviewers, and to update
> the docs (with spaces, not tabs) and the Makefiles (with tabs, not
> spaces) and the meson stuff and, as if that weren't enough already,
> you actually need the code to work! And that includes not only working
> regularly but also with CLOBBER_CACHE_ALWAYS and debug_parallel_query
> and so on. It's very easy to miss something somewhere. I put a LOT of
> work into polishing my commits before I push them, and it's still not
> that uncommon that I screw something up.


Yes, there's a lot to look out for, and you're a damn sight better at it 
than I am. But we should try to automate the things that can be 
automated, even if that leaves many tasks that can't be. I have three 
things in my pre-commit hook: a check for catalog updates, a check for 
new typedefs, and an indent check. And every one of them has saved me 
from doing things I should not be doing. They aren't perfect but they 
are useful.

Slightly off topic, but apropos your message, maybe we should recommend 
a standard git commit template.


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com