Re: run pgindent on a regular basis / scripted manner

Noah Misch <noah(at)leadboat(dot)com> writes:
> On Wed, Aug 12, 2020 at 07:47:01PM -0400, Tom Lane wrote:
>> 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.

> There are competing implementations of assuring pgindent-cleanliness at every
> check-in:

> 1. After each push, an automated followup commit appears, restoring
> pgindent-cleanliness.
> 2. "git push" results in a commit that melds pgindent changes into what the
> committer tried to push.
> 3. "git push" fails, for the master branch, if the pushed commit disrupts
> pgindent-cleanliness.

> Were you thinking of (2)?

I was objecting to (2). (1) would perhaps work. (3) could be pretty
darn annoying, especially if it blocks a time-critical security patch.

> Regarding typedefs.list, I would use the in-tree one, like you discussed here:

Yeah, after thinking about that more, it seems like automated
typedefs.list updates would be far riskier than automated reindent
based on the existing typedefs.list. The latter could at least be
expected not to change code unrelated to the immediate commit.
typedefs.list updates need some amount of adult supervision.

(I'd still vote for nag-mail to the committer whose work got reindented,
in case the bot made things a lot worse.)

I hadn't thought about the angle of HEAD versus back-branch patches,
but that does seem like something to ponder. The back branches don't
have the same pgindent rules necessarily, plus the patch versions
might be different in more than just whitespace. My own habit when
back-patching has been to indent the HEAD patch per-current-rules and
then preserve that layout as much as possible in the back branches,
but I doubt we could get a tool to do that with any reliability.

Of course, there's also the possibility of forcibly reindenting
all the active back branches to current rules. But I think we've
rejected that idea already, because it would cause so much pain
for forks that are following a back branch.

regards, tom lane