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

From Tom Lane
Subject Re: run pgindent on a regular basis / scripted manner
Date
Msg-id 328084.1597276021@sss.pgh.pa.us
Whole thread Raw
In response to Re: run pgindent on a regular basis / scripted manner  (Jesse Zhang <sbjesse@gmail.com>)
Responses Re: run pgindent on a regular basis / scripted manner  (Noah Misch <noah@leadboat.com>)
Re: run pgindent on a regular basis / scripted manner  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Jesse Zhang <sbjesse@gmail.com> writes:
> On Wed, Aug 12, 2020 at 3:34 PM Andres Freund wrote:
>> Is there any reason we don't just automatically run pgindent regularly?
>> Like once a week? And also update typedefs.list automatically, while
>> we're at it?

> You know what's better than weekly? Every check-in.

I'm not in favor of unsupervised pgindent runs, really.  It can do a lot
of damage to code that was written without thinking about it --- in
particular, it'll make a hash of comment blocks that were manually
formatted and not protected with dashes.

If the workflow is commit first and re-indent later, then we can always
revert the pgindent commit and clean things up manually; but an auto
re-indent during commit wouldn't provide that history.

I do like the idea of more frequent, smaller pgindent runs instead of
doing just one giant run per year.  With the giant runs it's necessary
to invest a fair amount of time eyeballing all the changes; if we did it
every couple weeks then the pain would be a lot less.

Another idea would be to have a bot that runs pgindent *without*
committing the results, and emails the people who have made commits
into files that changed, saying "if you don't like these diffs then
you'd better clean up your commit before it happens for real".  With
some warning like that, it might be okay to do automatic reindenting
a little bit later.  Plus, nagging committers who habitually commit
improperly-indented code might persuade them to clean up their acts ;-)

            regards, tom lane



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Parallel query hangs after a smart shutdown is issued
Next
From: Peter Geoghegan
Date:
Subject: Re: Add LWLock blocker(s) information