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

From Tom Lane
Subject Re: Maintaining a list of pgindent commits for "git blame" to ignore
Date
Msg-id 1647133.1624289645@sss.pgh.pa.us
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
Peter Geoghegan <pg@bowt.ie> writes:
> What do you think of the attached? I prefer the ISO date style myself,
> so I went with that.

I grepped the git logs for "indent" and found a bunch more commits
that look like they should be included:

db6e2b4c5
d84213909
1e9c85809
f04d4ac91
9ef2dbefc
651902deb
ce5548103
b5bce6c1e
de94e2af1
d0cd7bda9
befa3e648
7584649a1
84288a86a
d74714027
b6b71b85b
46785776c
089003fb4
ea08e6cd5
59f6a57e5

It's possible that some of these touch few enough lines that they
are not worth listing; I did not check the commit delta sizes.

> 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.

Meh.  I can get on board with the idea of adding commit+revert pairs
to this list, but I'd like a more principled selection filter than
"which ones bother Peter".  Maybe the size of the reverted patch
should factor into it.

Do we have an idea of how much adding entries to this list slows
down "git blame"?  If we include commit+revert pairs more than
very sparingly, I'm afraid we'll soon have an enormous list, and
I wonder what that will cost us.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Add version macro to libpq-fe.h
Next
From: Peter Geoghegan
Date:
Subject: Re: disfavoring unparameterized nested loops