Thread: pgsql: pgstat: run pgindent on pgstat.c/h.
pgstat: run pgindent on pgstat.c/h. Upcoming commits will touch a lot of the pgstats code. Reindenting separately makes it easier to keep the code in a well-formatted shape each step. Author: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/20220303021600.hs34ghqcw6zcokdh@alap3.anarazel.de Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/a3a75b982b5bb6fba95ad8b3d48e70439dcd2329 Modified Files -------------- src/backend/postmaster/pgstat.c | 28 ++++++++++++++++------------ src/include/pgstat.h | 4 ++-- src/tools/pgindent/typedefs.list | 3 +++ 3 files changed, 21 insertions(+), 14 deletions(-)
On Sat, Mar 19, 2022 at 11:45 AM Andres Freund <andres@anarazel.de> wrote: > pgstat: run pgindent on pgstat.c/h. Reminder: please add this commit to the .git-blame-ignore-revs file. -- Peter Geoghegan
On 2022-03-19 12:08:42 -0700, Peter Geoghegan wrote:
> On Sat, Mar 19, 2022 at 11:45 AM Andres Freund <andres@anarazel.de> wrote:
> > pgstat: run pgindent on pgstat.c/h.
>
> Reminder: please add this commit to the .git-blame-ignore-revs file.
I was actually wondering what our policy around that is for smaller runs like
this. Do we do that in bulk occasionally? Just after?
We're also missing the recent, a bit larger, reindent that Heikki did:
commit d231be00cbf29bf24e5b4fc79e587982bbc00ebb
Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
Date: 2022-02-16 09:22:34 +0200
Run pgindent on xlog.c.
On Sat, Mar 19, 2022 at 12:27 PM Andres Freund <andres@anarazel.de> wrote: > I was actually wondering what our policy around that is for smaller runs like > this. Do we do that in bulk occasionally? Just after? That's not completely clear, but I think that it makes sense to do it right afterwards. We haven't been maintaining a .git-blame-ignore-revs file for long enough, so maybe the workflow needs to be refined. Perhaps there should *also* be something in the RELEASE_CHANGES files about looking for overlooked pgindent files, too. It's not the end of the world if somebody forgets to do this, obviously. Ideally there would be some kind of reminder built into the pgindent tooling to make it less likely. > We're also missing the recent, a bit larger, reindent that Heikki did: > Run pgindent on xlog.c. I missed that one. -- Peter Geoghegan
Hi, Pushed an update including the two revs already discussed here, as well as ed43677e20369040ca4e50c698010c39d5ac0f47 # 2021-01-19 08:10:13 +0530 # pgindent worker.c. On 2022-03-19 12:36:29 -0700, Peter Geoghegan wrote: > Ideally there would be some kind of reminder built into the > pgindent tooling to make it less likely. I think a lot of pgindent runs are just to reindent changes during development, so that'd probably just join all the other stuff we learn to ignore :) Greetings, Andres Freund
On Sat, Mar 19, 2022 at 12:42 PM Andres Freund <andres@anarazel.de> wrote: > Pushed an update including the two revs already discussed here, as well as > ed43677e20369040ca4e50c698010c39d5ac0f47 # 2021-01-19 08:10:13 +0530 > # pgindent worker.c. Thanks. > I think a lot of pgindent runs are just to reindent changes during > development, so that'd probably just join all the other stuff we learn to > ignore :) Yeah, warning fatigue is inevitable. I've been adding pgindent commits that actually bother me while using git-blame for my work (a couple of much older pgindent commits). Maybe that approach is all that we really need. The amount of "blame noise" added by each individual pgindent commit varies wildly. Almost all of the problems (before .git-blame-ignore-revs was available) came from only a handful of historic pgindent commits. These commits were those that made major changes, like upgrading pg_bds_indent, or altering the indenting rules. Even the typical yearly (or biannual) pgindent run from Bruce doesn't create all that much noise. So again, maybe a pretty informal approach is fine here. -- Peter Geoghegan
Andres Freund <andres@anarazel.de> writes:
> On 2022-03-19 12:36:29 -0700, Peter Geoghegan wrote:
>> Ideally there would be some kind of reminder built into the
>> pgindent tooling to make it less likely.
> I think a lot of pgindent runs are just to reindent changes during
> development, so that'd probably just join all the other stuff we learn to
> ignore :)
Yeah ... you can't do anything about it at the time you run pgindent,
because you don't yet have the commit hash. So I don't see that such
a reminder will help much. The pgindent/README file does mention
that you ought to do this, so anyone following that recipe will
get it right.
regards, tom lane