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

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-committers <pgsql-committers(at)lists(dot)postgresql(dot)org>
Subject: Re: pgsql: pgstat: run pgindent on pgstat.c/h.
Date: 2022-03-19 19:51:53
Message-ID: CAH2-Wznsj6YSNjnabmNb9bo9id-Z_ACDsRT2jFm_3=tii4pnCA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

On Sat, Mar 19, 2022 at 12:42 PM Andres Freund <andres(at)anarazel(dot)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

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2022-03-19 19:52:15 Re: pgsql: pgstat: run pgindent on pgstat.c/h.
Previous Message Andres Freund 2022-03-19 19:42:30 Re: pgsql: pgstat: run pgindent on pgstat.c/h.