Re: run pgindent on a regular basis / scripted manner

Hi,

On 2023-01-22 18:28:27 -0500, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On 2023-01-22 18:20:49 +0100, Jelte Fennema wrote:
> >> I don't think the amount of pain is really much lower if we reformat
> >> 10,000 or 300,000 lines of code, without automation both would be
> >> quite painful. But the git commands I shared in my previous email
> >> should alleviate most of that pain.
>
> > It's practically not possible to review a 300k line change. And perhaps I'm
> > paranoid, but I would have a problem with a commit in the history that's
> > practically not reviewable.
>
> As far as that goes, if you had concern then you could run the indentation
> tool locally and confirm you got matching results.

Of course, but I somehow feel a change of formatting should be reviewable to
at least some degree. Even if it's just to make sure that the tool didn't have
a bug and cause some subtle behavioural change.

> So the more I think about it the less excited I am about depending on
> clang-format, because version skew in peoples' clang installations seems
> inevitable, and there's good reason to fear that that would show up
> as varying indentation results.

One thing that I like about clang-format is that it's possible to treat it
about our include order rules (which does find some "irregularities). But of
course that's not enough.

If we decide to move to another tool, I think it might be worth to remove a
few of the pg_bsd_indent options, that other tools won't be able to emulate,
first. E.g. -di12 -> -di4 would remove a *lot* of the noise from a move to
another tool. And be much easier to write manually, but ... :)

I think I've proposed this before, but I still think that as long as we rely
on pg_bsd_indent, we should have it be part of our source tree and
automatically built. It's no wonder that barely anybody indents their
patches, given that it requires building pg_bsd_ident in a separate repo (but
referencing our sourc etree), putting the binary in path, etc.

Greetings,

Andres Freund