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 git blame to ignore: the --ignore-revs-file` 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 .git-blame-ignore-revs 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:

  $ 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