Horton
Menu

Re: run pgindent on a regular basis / scripted manner

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, pgsql-hackers@postgresql.org
Date: 2020-08-17T19:25:52Z
Lists: pgsql-hackers 
Andres Freund <andres@anarazel.de> writes:
> On 2020-08-15 13:44:34 -0400, Tom Lane wrote:
>> Andres Freund <andres@anarazel.de> writes:
>>> One thing is that some here are actively against manually adding entries
>>> to typedefs.list.

>> I've been of the opinion that it's pointless to do so under the current
>> regime where (a) only a few people do that and (b) we only officially
>> re-indent once a year anyway.  When I want to manually run pgindent,
>> I always pull down a fresh typedefs.list from the buildfarm, which is
>> reasonably up-to-date regardless of what people added or didn't add,
>> and then add any new typedefs from my current patch to that out-of-tree
>> copy.

> Well, properly indenting new code still is worthwhile. And once you go
> through the trouble of adding the typedefs locally, I don't really see
> the reason not to also include them in the commit.

Yeah, I'm quite religious about making sure my commits have been through
pgindent already (mainly to reduce subsequent "git blame" noise).
However, relying on manual updates to the in-tree typedefs.list only
works if every committer is equally religious about it.  They're not;
else we'd not be having this discussion.  The workflow I describe above
is not dependent on how careful everybody else is, which is why I
prefer it.

I think that the main new idea that's come out of this thread so far
is that very frequent reindents would be as good, maybe better, as
once-a-year reindents in terms of the amount of rebasing pain they
cause for not-yet-committed patches.  If we can fix it so that any
mis-indented commit is quickly corrected, then rebasing would only be
needed in places that were changed anyway.  So it seems like that
would be OK as a new project policy if we can make it happen.

However, I don't see any way to make it happen like that without
more-or-less automated reindents and typedefs.list updates,
and that remains a bit scary.

I did just have an idea that seems to ameliorate the scariness
a good bit: allow the reindent bot to auto-commit its results
only if the only lines it's changing are ones that were touched
by commits since the last auto-reindent.  Otherwise punt and ask
a human to review the results.  Not sure how hard that is to
implement, though.

Another good safety check would be to not proceed unless the latest
typedefs list available from the buildfarm is newer than the last
commit --- then we won't mess up recent commits whose typedefs are
not in the list yet.

			regards, tom lane

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.