Horton

Re: The pgperltidy diffs in HEAD

Álvaro Herrera <alvherre@kurilemu.de>

View thread
From: Álvaro Herrera <alvherre@kurilemu.de>
To: Daniel Gustafsson <daniel@yesql.se>
Cc: Pgsql Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-11-25T15:49:32Z
Lists: pgsql-hackers

Commits

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

  1. Check for correct version of perltidy

On 2025-Nov-25, Daniel Gustafsson wrote:

> I routinely run pgperltidy src/ when hacking on things, and am greeted with
> lots of diffs like how pgindent runs used to be.  Are there objections to
> applying the diffs we've accumulated so far with a .git-blame-ignore-revs
> update alongside it? Are there reasons not that I am missing?

None here.  I tend to run pgperltidy on individual files so this is not
normally a problem for me, but I kinda dislike that our steady status is
not clean.

> Attached is the current output from pgperltidy, I haven't looked over it in
> detail but I am happy to take that on assuming it's not objected to.

Hmm, I wonder if you ran this with our documented version of perltidy.
I have vague memories of pgperltidy leaving the generate-lwlocknames.pl
script the way it is now, for example.  But then, maybe the one who used
the wrong perltidy version is me.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/