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

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Maintaining a list of pgindent commits for "git blame" to ignore
Date: 2021-03-18 22:03:41
Message-ID: CAH2-Wzk-6XMYJEYLCo7Zo1DZbUL53MbT6q8NEk1ot2bAZ82aYg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Mar 18, 2021 at 2:10 PM Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Actually, Tom Lane runs pgindent usually now. I do the copyright
> change, but I don't think we would ignore those since the single-line
> change is probably something we would want to blame.

The copyright change commits don't need to be considered here. In
practice they're just not a problem because nobody wants or expects
"git blame" to do anything more than attribute an affected line to a
copyright commit.

> It would certainly be very easy to pull pgindent commits out of git log
> and add them. I do wish we could cause everyone to honor that file, but
> it seems each user has to configure their repository to honor it.

That doesn't seem like a huge problem. There is no reason why this
shouldn't be easy to use and to maintain going forward. There just
aren't very many commits involved.

Attached is my .git-blame-ignore-revs file, which has pgindent commits
that I'd like to exclude from git blame. The file is helpful on its
own. But what we really ought to do is commit the file (perhaps with
some revisions) and require that it be maintained by the official
project workflow documented at src/tools/pgindent/README.

--
Peter Geoghegan

Attachment Content-Type Size
pgindent-git-blame-ignore-revs application/octet-stream 4.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2021-03-18 22:08:32 Re: a verbose option for autovacuum
Previous Message Sean Jezewski 2021-03-18 21:59:34 PG13 fails to startup even though the current transaction is equal to the target transaction