What did you do before the bug happened? 1. Commit changes to <FILE> 2. Observe that this commit has a hash of <HASH>, e.g. through git rev-parse HEAD 3. Run `echo <HASH> > .git-blame-ignore-revs` 4. Run `git config blame.ignoreRevsFile .git-blame-ignore-revs` 5. Run `git blame <FILE>` 6. Run `git blame --ignore-revs-file=.git-blame-ignore-revs <FILE>` 7. Run `git blame --ignore-rev=<HASH> <FILE>` What did you expect to happen? (Expected behavior) The three git blame commands should attribute each line of the source file to a commit, but none of those commits should be the one specified by <HASH>. What happened instead? (Actual behavior) All three git blame commands included lines attributed to <HASH>. What's different between what you expected and what actually happened? The commit identified by <HASH> was not ignored. Anything else you want to add: I tried this in a brand new repository and everything worked as expected. I do not know why it is only failing in this repository. It is a large repository I use for work, but I'm using the same version of Git in both places. [System Info] git version: git version 2.28.0 cpu: x86_64 no commit associated with this build sizeof-long: 8 sizeof-size_t: 8 shell-path: /bin/sh uname: Darwin 18.7.0 Darwin Kernel Version 18.7.0: Mon Apr 27 20:09:39 PDT 2020; root:xnu-4903.278.35~1/RELEASE_X86_64 x86_64 compiler info: clang: 11.0.0 (clang-1100.0.33.17) libc info: no libc information available $SHELL (typically, interactive shell): /usr/local/bin/bash [Enabled Hooks] post-commit post-checkout post-merge pre-push
