As you can't know the hash before commiting, I don't see a way to keep the ignore file updated within a single commit.

Instead of keeping this file, you could run something like this:

git blame $(for hash in $(git log --format="%H"); do echo "--ignore-rev" $hash; done) -- file

git log --format="%H" will provide the hashes, and you can change it to return only the ones you need - such as git log --grep="some text" --format="%H", assuming that all commits you want to ignore have some text in common, etc. If there's no such thing, you'll have to find another way to filter the commits.

Then the for loop takes all the hashes and passes them to git blame, in the form of --ignore-rev parameters (the docs says this option can be specified multiple times).

That is a crazy cool idea. Totally avoids the ignoreRevsFile file. Relies on convention of commit messages. I wonder if this would have performance impacts. Maybe I need a cron job to regenerate my ignoreRevsFile, or do that at each git pull and don't check it in. I need to think about this.

I don't see how this can have a significant impact on performance. Git is incredibly fast and a simple git log with some filters shouldn't take so long to run. Unless you're dealing with a really huge repository and runs git blame millions of times a day, which I don't think it's the case. Anyway, the best way to know is to make some tests and see how it goes.

Regarding the cron job idea, you could keep the ignoreRevs file in another location, outside of your project, so it doesn't interfere with the project's commits.