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

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Maintaining a list of pgindent commits for "git blame" to ignore
Date: 2021-06-23 00:11:41
Message-ID: CAH2-WzmL9202Ck6kRhV5_iG8pj2WhZhiYqdwO_xkVg8rxVm+Rw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jun 22, 2021 at 5:01 PM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> I have 2.30. It works better. To be clear: some lines still appear as
> originating in some pgindent commit, when they are created by such a
> commit. But as far as I've seen, they're mostly uninteresting ones
> (whitespace, only braces, only "else", only "for (;;)" and similar).

As I understand it there are a small number of remaining lines that
are fundamentally impossible to attribute to any commit but a pgindent
commit. These are lines that a pgindent commit created, typically when
it adds a new single line of whitespace (carriage return). I think
that these remaining lines of whitespace probably *should* be
attributed to a pgindent commit -- it's actually a good thing. In any
case they're unlikely to be called up because they're just whitespace.

> The git blame experience seems much better. Thanks!

I'm very pleased with the results myself.

It's particularly nice when you "git blame" an old file that has been
through multiple huge pgindent changes. You can actually see
reasonable attributions for commits that go back to the 1990s now.

--
Peter Geoghegan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2021-06-23 00:17:17 Re: Use simplehash.h instead of dynahash in SMgr
Previous Message Alvaro Herrera 2021-06-23 00:00:55 Re: Maintaining a list of pgindent commits for "git blame" to ignore