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-WzmL9202Ck6kRhV5_iG8pj2WhZhiYqdwO_xkVg8rxVm+Rw@mail.gmail.com
Whole thread Raw
In response to Re: Maintaining a list of pgindent commits for "git blame" to ignore  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
On Tue, Jun 22, 2021 at 5:01 PM Alvaro Herrera <alvherre@alvh.no-ip.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



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Maintaining a list of pgindent commits for "git blame" to ignore
Next
From: Thomas Munro
Date:
Subject: Re: Use simplehash.h instead of dynahash in SMgr