Horton
Menu

Re: run pgindent on a regular basis / scripted manner

Jelte Fennema <postgres@jeltef.nl>

View thread
From: Jelte Fennema <postgres@jeltef.nl>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Bruce Momjian <bruce@momjian.us>, 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>, Noah Misch <noah@leadboat.com>, Jesse Zhang <sbjesse@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2023-01-24T16:03:25Z
Lists: pgsql-hackers 
> As a concrete example, suppose Alice commits some code that uses "foo"
> as a variable name, and more or less concurrently, Bob commits something
> that defines "foo" as a typedef.  Bob's change is likely to have
> side-effects on the formatting of Alice's code.  If they're working in
> well-separated parts of the source tree, nobody is likely to notice
> that for awhile --- but whoever next touches the files Alice touched
> will be in for a surprise, which will be more or less painful depending
> on whether we've installed brittle processes.

Sounds like this conflict could be handled fairly easily by
having a local git hook rerunning pgindent whenever
you rebase a commit:
1. if you changed typedefs.list the hook would format all files
2. if you didn't it only formats the files that you changed

> 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.

Wouldn't the automatic addition-only solution that Andres suggested
solve this issue? Build farms could still remove unused typedefs
on a regular basis, but commits would at least add typedefs for the
platform that the comitter uses.

> I think we need to be content with a "soft", it's more-or-less-right
> approach to indentation.

I think that this would already be a significant improvement over the
current situation. My experience with the current situation is that
indentation is more-or-less-wrong.

> As I explained to somebody upthread, the
> main benefit of this for most people is avoiding the need for a massive
> once-a-year reindent run that causes merge failures for many pending
> patches.

Merge failures are one issue. But personally the main benefit that
I would be getting is being able to run pgindent on the files
I'm editing and get this weird +12 columns formatting correct
without having to manually type it. Without pgindent also
changing random parts of the files that someone else touched
a few commits before me.

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.