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: Magnus Hagander <magnus@hagander.net>, Amit Kapila <amit.kapila16@gmail.com>
Cc: Noah Misch <noah@leadboat.com>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>, Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@anarazel.de>, Bruce Momjian <bruce@momjian.us>, Jelte Fennema <postgres@jeltef.nl>, Peter Geoghegan <pg@bowt.ie>, Alvaro Herrera <alvherre@2ndquadrant.com>, Stephen Frost <sfrost@snowman.net>, Jesse Zhang <sbjesse@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2023-02-07T13:33:33Z
Lists: pgsql-hackers 
On 2023-02-07 Tu 07:59, Magnus Hagander wrote:
>
>
> On Tue, Feb 7, 2023 at 1:56 PM Amit Kapila <amit.kapila16@gmail.com> 
> wrote:
>
>     On Tue, Feb 7, 2023 at 5:16 PM Andrew Dunstan
>     <andrew@dunslane.net> wrote:
>     >
>     > On 2023-02-06 Mo 23:43, Noah Misch wrote:
>     >
>     >
>     > Well, we did talk about adding a pre-commit hook to the
>     repository, with
>     > instructions for how to enable it. And I don't see a problem
>     with adding the
>     > pre-receive we're discussing here to src/tools/something.
>     >
>     > Yeah.  I don't think we are seriously considering putting any
>     restrictions
>     > in place on gitmaster
>     >
>     > I could have sworn that was exactly what we were discussing, a
>     pre-receive
>     > hook on gitmaster.
>     >
>     >
>     > That's one idea that's been put forward, but it seems clear that
>     some people are nervous about it.
>     >
>     > Maybe a better course would be to continue improving the toolset
>     and get more people comfortable with using it locally and then
>     talk about integrating it upstream.
>     >
>
>     Yeah, that sounds more reasonable to me as well.
>
>
> If we wanted something "in between" we could perhaps also have a async 
> ci job that runs after each commit and sends an emali to the committer 
> if the commit doesn't match up, instead of rejecting it hard but still 
> getting some relatively fast feedback.


Sure, worth trying. We can always turn it off and no harm done if it 
doesn't suit. I'd probably start by having it email a couple of guinea 
pigs like you and me before turning it loose on committers generally. 
LMK if you need help with it.


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.