Re: run pgindent on a regular basis / scripted manner - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: run pgindent on a regular basis / scripted manner
Date
Msg-id 1215f2de-3c49-eb3a-e62b-da1c05cb51db@dunslane.net
Whole thread Raw
In response to Re: run pgindent on a regular basis / scripted manner  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: run pgindent on a regular basis / scripted manner
List pgsql-hackers
On 2023-02-02 Th 01:40, Tom Lane wrote:
> Noah Misch <noah@leadboat.com> writes:
>> Regarding the concern about a pre-receive hook blocking an emergency push, the
>> hook could approve every push where a string like "pgindent: no" appears in a
>> commit message within the push.  You'd still want to make the tree clean
>> sometime the same week or so.  It's cheap to provide a break-glass like that.
> I think the real question here is whether we can get all (or at least
> a solid majority of) committers to accept such draconian constraints.
> I'd buy into it, and evidently so would you, but I can't help noting
> that less than a quarter of active committers have bothered to
> comment on this thread.  I suspect the other three-quarters would
> be quite annoyed if we tried to institute such requirements.  That's
> not manpower we can afford to drive away.


I'd be very surprised if this caused any active committer to walk away
from the project. Many will probably appreciate the nudge. But maybe I'm
overoptimistic.


>
> Maybe this should get taken up at the this-time-for-sure developer
> meeting at PGCon?
>
>             


Sure. There's probably some work that could still be done in this area
too, such as making pgperltidy work similarly to how we've now make
pgindent work.


There's also a question of timing. Possibly the best time would be when
we next fork the tree.


cheers


andrew

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




pgsql-hackers by date:

Previous
From: "jacktby@gmail.com"
Date:
Subject: How to write a new tuple into page?
Next
From: Alvaro Herrera
Date:
Subject: Re: pg_stat_statements and "IN" conditions