Re: pgsql: pgstat: run pgindent on pgstat.c/h.
От | Peter Geoghegan |
---|---|
Тема | Re: pgsql: pgstat: run pgindent on pgstat.c/h. |
Дата | |
Msg-id | CAH2-Wznsj6YSNjnabmNb9bo9id-Z_ACDsRT2jFm_3=tii4pnCA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pgsql: pgstat: run pgindent on pgstat.c/h. (Andres Freund <andres@anarazel.de>) |
Список | pgsql-committers |
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
В списке pgsql-committers по дате отправления: