Horton
Menu

Re: run pgindent on a regular basis / scripted manner

Andrew Dunstan <andrew@dunslane.net>

View thread
From: Andrew Dunstan <andrew@dunslane.net>
To: Robert Haas <robertmhaas@gmail.com>, Jelte Fennema <postgres@jeltef.nl>
Cc: Peter Geoghegan <pg@bowt.ie>, Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@anarazel.de>, Michael Paquier <michael@paquier.xyz>, "shiy.fnst@fujitsu.com" <shiy.fnst@fujitsu.com>, Justin Pryzby <pryzby@telsasoft.com>, Noah Misch <noah@leadboat.com>, Bruce Momjian <bruce@momjian.us>, Magnus Hagander <magnus@hagander.net>, Alvaro Herrera <alvherre@2ndquadrant.com>, Stephen Frost <sfrost@snowman.net>, Jesse Zhang <sbjesse@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Date: 2023-10-24T13:40:01Z
Lists: pgsql-hackers 
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

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix comment from commit 22655aa231.

  2. Add a few recent commits to .git-blame-ignore-revs.

  3. Pre-beta2 mechanical code beautification.

  4. Pre-beta mechanical code beautification.

  5. Make agreed-on updates in perltidy options.

  6. Remove obsolete pgindent options --code-base and --build

  7. Integrate pg_bsd_indent into our build/test infrastructure.

  8. Sync pg_bsd_indent's copyright notices with Postgres practice.

  9. Import pg_bsd_indent sources.

  10. pgindent: filter files for the --commit option

  11. pgindent: more ways to find files to indent

  12. Fix pgindent --show-diff option.

  13. Add non-destructive modes to pgindent

  14. Initial pgindent run with pg_bsd_indent version 2.0.