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