pgsql: pgstat: run pgindent on pgstat.c/h.

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