Horton
Menu

Re: run pgindent on a regular basis / scripted manner

Magnus Hagander <magnus@hagander.net>

View thread
From: Magnus Hagander <magnus@hagander.net>
To: Stephen Frost <sfrost@snowman.net>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Noah Misch <noah@leadboat.com>, Jesse Zhang <sbjesse@gmail.com>, Andres Freund <andres@anarazel.de>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2020-08-13T16:58:50Z
Lists: pgsql-hackers 
On Thu, Aug 13, 2020 at 6:30 PM Stephen Frost <sfrost@snowman.net> wrote:

>
> * Magnus Hagander (magnus@hagander.net) wrote:
>
> > There are many solutions that do such things but that do it in the
> "github
> > workflow" way, which is they do change -> commit -> create pull request,
> > and then somebody eyeballs that pullrequest and approves it. We don't
> have
> > PRs, but we could either have a script that simply sends out a patch to a
> > mailinglist, or we could have a script that maintains a separate branch
> > which is auto-pgindented, and then have a committer squash-merge that
> > branch after having reviewed it.
> >
> > Maybe something like that in combination with a pre-commit hook per
> above.
>
> So, in our world, wouldn't this translate to 'make cfbot complain'?
>
> I'm definitely a fan of the idea of having cfbot flag these and then we
> maybe get to a point where it's not the committers dealing with fixing
> patches that weren't pgindent'd properly, it's the actual patch
> submitters being nagged about it...
>

Werll, that's one thing, but what I was thinking of here was more of an
automated branch maintained for the committers, not for the individual
patch owners.

That is:
1. Whenever a patch is pushed on master on the main repo a process kicked
off (or maybe wait 5 minutes to coalesce multiple patches if there are)
2. This process checks out master, and runs pgindent on it
3. When done, this gets committed to a new branch (or just overwrites an
existing branch of course, we don't need to maintain history here) like
"master-indented". This branch can be in a different repo, but one that
starts out as a clone of the main one
4. A committer (any committer) can then on regular basis examine the
differences by fetch + diff. If they're happy with it, cherry pick it in.
If not, figure out what needs to be done to adjust it.

Step 4 can be done at whatever interval we prefer, and we can have
something to nag us if head has been "off-indent"  for too long.

This would be the backup for things that aren't indented during patch
commit, not other things.

-- 
 Magnus Hagander
 Me: https://www.hagander.net/ <http://www.hagander.net/>
 Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>

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.