Re: run pgindent on a regular basis / scripted manner

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Nikita Malakhov <hukutoc(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Jelte Fennema <postgres(at)jeltef(dot)nl>, Peter Geoghegan <pg(at)bowt(dot)ie>, Bruce Momjian <bruce(at)momjian(dot)us>, Magnus Hagander <magnus(at)hagander(dot)net>, Stephen Frost <sfrost(at)snowman(dot)net>, Noah Misch <noah(at)leadboat(dot)com>, Jesse Zhang <sbjesse(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: run pgindent on a regular basis / scripted manner
Date: 2023-01-23 20:09:10
Message-ID: 1921830.1674504550@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Nikita Malakhov <hukutoc(at)gmail(dot)com> writes:
> I've ran pdindent on the whole Postgres and it'd changed
> an awful lot of source files. Won't it create a lot of merge conflicts?

Well, yeah, you've rediscovered the fact that a lot of commits are sloppy
about this, and it's been awhile since our last tree-wide pgindent.

Our normal process has been to do a cleanup pgindent run annually or so,
usually after the end of the last commitfest of a cycle when there's
plenty of time for people to deal with the ensuing merge conflicts.

If we could get to "commits are pgindent clean to begin with", we
could avoid the merge problems from one-big-reindent. I'd still
be inclined to do an annual run as a backup, but hopefully it would
find few problems.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David G. Johnston 2023-01-23 20:09:36 v16 GRANT role TO role needs a multi-option setting capability
Previous Message Pavel Stehule 2023-01-23 20:09:07 Re: Schema variables - new implementation for Postgres 15 (typo)