On 2025-12-31 We 10:26 AM, Tom Lane wrote:
Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> writes:
On Wed, Dec 31, 2025 at 5:06 PM Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
This tries to make running formatting a lot easier for committers, but
primarily for new contributors.
I generally like the idea. Since perltidy is not enforced regularly
(like pgindent), running it usually ends up modifying files which are
not part of the patch. So I avoid it if not necessary. Do you propose
to make it optional?
The other obstacle is that not everybody will have the right version
of perltidy installed, but using some other version will create a
whole lot of extraneous noise.
pgperltidy actually checks the version now.
On the whole I'd recommend not trying to automate the perltidy
step yet. Cost/benefit is just not very good.
I'd kinda like to unify these universes, though. We could import the pgperltidy logic into pgindent but disable it unless some flag were given and the correct version of perltidy were present.
On the substance of the patch: I wonder whether we could make things
more reliable by using git metadata to figure out which .h and .c
files to point pgindent at.
The git pre-commit hook I use operates with this set of files:
files=$(git diff --cached --name-only --diff-filter=ACMR)
pgindent just currently looks at that set of files and ignores everything that's not a .c or .h file.
I guess what you're wanting is a test to see if the file is in git or a generated file? That doesn't really arise for me as I always do vpath builds, so generated files are always elsewhere.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
