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

From Peter Geoghegan
Subject Re: run pgindent on a regular basis / scripted manner
Date
Msg-id CAH2-WzmhQv=F3oJEvimz2bTFTbXwfJz6eC=1rxSdgRQQYq94nQ@mail.gmail.com
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
Re: run pgindent on a regular basis / scripted manner
List pgsql-hackers
On Mon, Oct 16, 2023 at 5:45 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Two thoughts about that:
>
> 1. We should not commit indent fixups on behalf of somebody else's
> misindented commit.  Peer pressure on committers who aren't being
> careful about this is the only way to improve matters; so complain
> to the person at fault until they fix it.

Thomas Munro's recent commit 01529c704008 was added to
.git-blame-ignore-revs by Michael Paquier, despite the fact that
Munro's commit technically isn't just a pure indentation fix (it also
fixed some typos). It's hard to judge Michael too harshly for this,
since in general it's harder to commit things when koel is already
complaining about existing misindetation -- I get why he'd prefer to
take care of that first.

> 2. We could raise awareness of this issue by adding indent verification
> to CI testing.  I hesitate to suggest that, though, for a couple of
> reasons:
>    2a. It seems fairly expensive, though I might be misjudging.
>    2b. It's often pretty handy to submit patches that aren't fully
>    indent-clean; I have such a patch in flight right now at [1].

It's also often handy to make a minor change to a comment or something
at the last minute, without necessarily having the comment indented
perfectly.

> 2b could be ameliorated by making the indent check be a separate
> test process that doesn't obscure the results of other testing.

I was hoping that "go back to the old status quo" would also appear as
an option.

My main objection to the new policy is that it's not quite clear what
process I should go through in order to be 100% confident that koel
won't start whining (short of waiting around for koel to whine). I
know how to run pgindent, of course, and haven't had any problems so
far...but it still seems quite haphazard. If we're going to make this
a hard rule, enforced on every commit, it should be dead easy to
comply with the rule.

--
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Quan Zongliang
Date:
Subject: Re: PL/pgSQL: Incomplete item Allow handling of %TYPE arrays, e.g. tab.col%TYPE[]
Next
From: Quan Zongliang
Date:
Subject: Re: PL/pgSQL: Incomplete item Allow handling of %TYPE arrays, e.g. tab.col%TYPE[]