Maintaining a list of pgindent commits for "git blame" to ignore - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Maintaining a list of pgindent commits for "git blame" to ignore
Date
Msg-id CAH2-Wz=cVh3GHTP6SdLU-Gnmt2zRdF8vZkcrFdSzXQ=WhbWm9Q@mail.gmail.com
Whole thread Raw
Responses Re: Maintaining a list of pgindent commits for "git blame" to ignore
List pgsql-hackers
Recent versions of git are capable of maintaining a list of commits
for "git blame" to ignore:

https://www.moxio.com/blog/43/ignoring-bulk-change-commits-with-git-blame

I tried this out myself, using my own list of pgindent commits. It
works very well -- much better than what you get when you ask git to
heuristically ignore commits based on whitespace-only line changes.
This is not surprising, in a way; I don't actually want to avoid
whitespace. I just want to ignore pgindent commits.

Note that there are still a small number of pgindent line changes,
even with this. That's because sometimes it's unavoidable -- some
"substantively distinct lines of code" are actually created by
pgindent. But these all seem to be <CR> lines that are only shown
because there is legitimately no more appropriate commit to attribute
the line to. This seems like the ideal behavior to me.

I propose that we (I suppose I actually mean Bruce) start maintaining
our own file for this in git. It can be configured to run without any
extra steps via a once-off "git config blame.ignoreRevsFile
.git-blame-ignore-revs". It would only need to be updated whenever
Bruce or Tom runs pgindent.

It doesn't matter if this misses one or two smaller pgindent runs, it
seems. Provided the really huge ones are in the file, everything works
very well.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: default result formats setting
Next
From: Tomas Vondra
Date:
Subject: Re: cleanup temporary files after crash