Horton
Menu

Re: run pgindent on a regular basis / scripted manner

Andres Freund <andres@anarazel.de>

View thread
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jelte Fennema <postgres@jeltef.nl>, Peter Geoghegan <pg@bowt.ie>, Bruce Momjian <bruce@momjian.us>, Magnus Hagander <magnus@hagander.net>, Alvaro Herrera <alvherre@2ndquadrant.com>, Stephen Frost <sfrost@snowman.net>, Noah Misch <noah@leadboat.com>, Jesse Zhang <sbjesse@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2023-01-23T00:15:18Z
Lists: pgsql-hackers 
Hi,

On 2023-01-22 18:28:27 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.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

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix comment from commit 22655aa231.

  2. Add a few recent commits to .git-blame-ignore-revs.

  3. Pre-beta2 mechanical code beautification.

  4. Pre-beta mechanical code beautification.

  5. Make agreed-on updates in perltidy options.

  6. Remove obsolete pgindent options --code-base and --build

  7. Integrate pg_bsd_indent into our build/test infrastructure.

  8. Sync pg_bsd_indent's copyright notices with Postgres practice.

  9. Import pg_bsd_indent sources.

  10. pgindent: filter files for the --commit option

  11. pgindent: more ways to find files to indent

  12. Fix pgindent --show-diff option.

  13. Add non-destructive modes to pgindent

  14. Initial pgindent run with pg_bsd_indent version 2.0.