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: Andrew Dunstan <andrew@dunslane.net>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, 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-24T18:42:18Z
Lists: pgsql-hackers 
> I think that would be undesirable, because then reindentation noise
> in completely-unrelated files would get baked into feature commits,
> complicating review and messing up "git blame" history.

With a rebase hook similar to the the pre-commit hook that I shared
upthread, your files will be changed accordingly, but you don't need
to commit those changes in the same commit as the one that you're
rebasing. You could append another commit after it. Another option
would be to move the typedefs.list change to a separate commit
together with all project wide indentation changes.

> The real bottom line here is that AFAICT, there are fewer committers
> who care about indent cleanliness than committers who do not, so
> I do not think that the former group get to impose strict rules
> on the latter, much as I might wish otherwise.

Is this actually the case? I haven't seen anyone in this thread say
they don't care. From my perspective it seems like the unclean
indents simply come from forgetting to run pgindent once in
a while. And those few forgetful moments add up over a year.
of commits. That's why to me tooling seems the answer here.
If the tooling makes it easy not to forget then the problem
goes away.

> FWIW, Andrew's recent --show-diff feature for pgindent has
> already improved my workflow for that.  I can do
> "pgindent --show-diff >fixindent.patch", manually remove any hunks
> in fixindent.patch that don't pertain to the code I'm working on,
> and apply what remains to fix up my new code.  (I had been doing
> something basically like this, but with more file-copying steps
> to undo pgindent's edit-in-place behavior.)

Yeah, I have a similar workflow with the pre-commit hook that
I shared. By using "git checkout -p" I can remove hunks that
don't pertain to my code. Still it would be really nice not
to have to go through that effort (which is significant for the
libpq code that I've been workin on, since there's ~50
incorrectly indented hunks).

> Here's another improvement I think will be useful when the new gadgets
> are used in a git hook: first, look for the excludes file under the
> current directory if we aren't setting $code_base (e.g if we have files
> given on the command line), and second apply the exclude patterns to the
> command line files as well as to files found using File::Find.

Change looks good to 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.