Re: Maintaining a list of pgindent commits for "git blame" to ignore

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Maintaining a list of pgindent commits for "git blame" to ignore
Дата
Msg-id 1647133.1624289645@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Maintaining a list of pgindent commits for "git blame" to ignore  (Peter Geoghegan <pg@bowt.ie>)
Ответы Re: Maintaining a list of pgindent commits for "git blame" to ignore  (Peter Geoghegan <pg@bowt.ie>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Add version macro to libpq-fe.h
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: disfavoring unparameterized nested loops