Automatic code linters and formatters are a handy way to get consistent
formatting across a codebase and avoid those painful bikeshedding arguments over
exactly where the curly braces should go. But running one on an existing
codebase has always come at a cost: the mess it creates in a commit history as
the formatting commits insert themselves all over the
git blame output,
diverting you from the commits that made the last meaningful change. In fact
this is often cited as the main reason folks won’t run a formatter on older
codebases where the history is an important source of documentation.
Well as of Git 2.23 there is a way to configure a list of commits for
to ignore: the
option. Let’s see how this works…
1. Create a file listing all the formatting commits
First, create a file in your repository called something like
and add all the SHAs for the commits that you want to be ignored. If you’re not
sure which commits these are, you can use
git log’s search functionality to
dig them out. For example
git log --grep "lint" will list all the commits that
contain the word “lint” in the commit message. One gotcha to be aware of: you’ll
need to use the full commit SHAs, otherwise it won’t work.
2. Configure your local repo to automatically use this ignore file
Once you have this file, you can either use it explicitly every time you run
$ git blame some-file.rb --ignore-revs-file .git-blame-ignore-revs
Or configure Git to automatically use the ignore list:
$ git config blame.ignoreRevsFile .git-blame-ignore-revs
Note this sets the configuration for your local copy of the repository. Your work colleagues will need to do the same if they want to take advantage of the ignore list.
So there you have it. A way that we can blame away without getting distracted by those pesky formatting commits.
More articles on Git