Re: The pgperltidy diffs in HEAD
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Álvaro Herrera <alvherre@kurilemu.de>
Cc: Daniel Gustafsson <daniel@yesql.se>,
Pgsql Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-11-25T16:00:51Z
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 →
-
Check for correct version of perltidy
- 1cdb84bb1bcd 19 (unreleased) landed
=?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de> writes: > 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. While I've not got any great objection to running pgperltidy now, it seems like it'd be better if committers were all on the same page about this. My understanding of the current policy is that we'll keep the tree pgindent-clean on the fly, but worry about pgperltidy only once a year or so. Is there consensus for tightening that up? > Hmm, I wonder if you ran this with our documented version of perltidy. This sort of thing is why I'm hesitant. We didn't really dare expect committers to ensure pgindent cleanliness until we had that tool fully integrated in our tree, so that there was one true (and readily available) version to use. perltidy still fails that test AFAIK; you have to go looking for the agreed-on version. regards, tom lane