Re: Maintaining a list of pgindent commits for "git blame" to ignore - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Maintaining a list of pgindent commits for "git blame" to ignore
Date
Msg-id CAH2-WzkUxD-f1+iG+XvKQR6BdQQeMAxoMNmkC+DQ1YqVs2MmOw@mail.gmail.com
Whole thread Raw
In response to Re: Maintaining a list of pgindent commits for "git blame" to ignore  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: Maintaining a list of pgindent commits for "git blame" to ignore
List pgsql-hackers
On Thu, Mar 18, 2021 at 4:32 PM Peter Geoghegan <pg@bowt.ie> wrote:
> On Thu, Mar 18, 2021 at 4:05 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > b5d69b7c22ee4c44b8bb99cfa0466ffaf3b5fab9  # Sun Jun 7 16:57:08 2020 -0400
> > # pgindent run prior to branching v13.
> >
> > which is easy to make from "git log" or "git show" output.  (Because
> > of the precedent of those tools, I'd rather write the commit hash
> > before the rest of the entry.)
>
> WFM.

What do you think of the attached? I prefer the ISO date style myself,
so I went with that.

Note that I have included "Modify BufferGetPage() to prepare for
"snapshot too old" feature", as well as "Revert no-op changes to
BufferGetPage()". I've noticed that those two particular commits cause
unhelpful noise when I run "git blame" on access method code. I see
problems with these commits often enough to matter. The latter commit
cleanly reverted the former after only 12 days, so ignoring both seems
okay to me.

Everything else should be either pgindent/perltidy related or
reformat-dat-files related.

-- 
Peter Geoghegan

Attachment

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Optionally automatically disable logical replication subscriptions on error
Next
From: Sandeep Thakkar
Date:
Subject: Re: [PATCH v3 1/1] Fix detection of preadv/pwritev support for OSX.