Horton
Menu

Re: run pgindent on a regular basis / scripted manner

Noah Misch <noah@leadboat.com>

View thread
From: Noah Misch <noah@leadboat.com>
To: Bruce Momjian <bruce@momjian.us>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Jelte Fennema <postgres@jeltef.nl>, Andres Freund <andres@anarazel.de>, Peter Geoghegan <pg@bowt.ie>, Magnus Hagander <magnus@hagander.net>, Alvaro Herrera <alvherre@2ndquadrant.com>, Stephen Frost <sfrost@snowman.net>, Jesse Zhang <sbjesse@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2023-02-02T06:28:38Z
Lists: pgsql-hackers 
On Mon, Jan 30, 2023 at 03:42:09PM -0500, Bruce Momjian wrote:
> On Sat, Jan 28, 2023 at 05:06:03PM -0800, Noah Misch wrote:
> > On Tue, Jan 24, 2023 at 02:04:02PM -0500, Bruce Momjian wrote:
> > > On Tue, Jan 24, 2023 at 09:54:57AM -0500, Tom Lane wrote:
> > > > As another example, the mechanisms we use to create the typedefs list
> > > > in the first place are pretty squishy/leaky: they depend on which
> > > > buildfarm animals are running the typedef-generation step, and on
> > > > whether anything's broken lately in that code --- which happens on
> > > > a fairly regular basis (eg [1]).  Maybe that could be improved,
> > > > but I don't see an easy way to capture the set of system-defined
> > > > typedefs that are in use on platforms other than your own.  I
> > > > definitely do not want to go over to hand maintenance of that list.
> > > 
> > > As I now understand it, we would need to standardize on a typedef list
> > > at the beginning of each major development cycle, and then only allow
> > > additions,
> > 
> > Not to my knowledge.  There's no particular obstacle to updating the list more
> > frequently or removing entries.
> 
> We would need to re-pgindent the tree each time, I think, which would
> cause disruption if we did it too frequently.

More important than frequency is how much old code changes.  A new typedef
typically is an identifier not already appearing in the tree, so no old code
changes.  A removed typedef typically no longer appears in the tree, so again
no old code changes.  The tree can get those daily; they're harmless.

The push that adds or removes FooTypedef from the source code is in the best
position to react to any surprising indentation consequences of adding or
removing FooTypedef from typedefs.list.  (Reactions could include choosing a
different typedef name or renaming incidental matches in older code.)  Hence,
changing typedefs.list as frequently as it affects the code is less disruptive
than changing it once a year.  The same applies to challenges like pgindent
wrecking a non-"/*----------" comment.  Such breakage is hard to miss when
it's part of the push that crafts the comment; it's easier to miss in a bulk,
end-of-cycle pgindent.

Regarding the concern about a pre-receive hook blocking an emergency push, the
hook could approve every push where a string like "pgindent: no" appears in a
commit message within the push.  You'd still want to make the tree clean
sometime the same week or so.  It's cheap to provide a break-glass like that.

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.