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-WzkNpDGK7LePYvXv4bCcb0BtnKF9x2+q3qsC=LOZc9HNDg@mail.gmail.com
Whole thread Raw
In response to Re: Maintaining a list of pgindent commits for "git blame" to ignore  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Maintaining a list of pgindent commits for "git blame" to ignore
Re: Maintaining a list of pgindent commits for "git blame" to ignore
List pgsql-hackers
On Thu, Mar 18, 2021 at 4:05 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> b5d69b7c22ee4c44b8bb99cfa0466ffaf3b5fab9  # Sun Jun 7 16:57:08 2020 -0400
> # pgindent run prior to branching v13.
>
> which is easy to make from "git log" or "git show" output.  (Because
> of the precedent of those tools, I'd rather write the commit hash
> before the rest of the entry.)

WFM.

What about reformat-dat-files and perltidy runs? It seems that you
have sometimes used all three reformatting tools to produce one commit
-- but not always. ISTM that I should get any of those that I missed.
And that the pgindent README (which already mentions these other
tools) ought to be updated to be explicit about the policy applying
equally to commits that apply any of the two other tools in bulk.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Maintaining a list of pgindent commits for "git blame" to ignore
Next
From: Ajin Cherian
Date:
Subject: Re: [HACKERS] logical decoding of two-phase transactions