Mark pure reformatting PRs in .git-blame-ignore-revs

[jakkdl]

This is mostly relevant to @CoolCat467 as you're in the progress of cleaning up the repository, but I realize we in general haven't been great at keeping that file updated.

See discussion in #2686 and #2692

It would be great if one could have a check that warned about this ... but I have no clue how that would work in any way, and I'm also not sure if it's possible to learn the commit ID's before merging such that you can actually add a PR to the file before it gets merged.

[A5rocks]

I'm also not sure if it's possible to learn the commit ID's before merging such that you can actually add a PR to the file before it gets merged.

I don't think so, because it'll use the current timestamp. Is there anything you think should get ignored? I looked at the blame for the abc file and the only ones I see are at least 4 years old.

[jakkdl]

I'm also not sure if it's possible to learn the commit ID's before merging such that you can actually add a PR to the file before it gets merged.

I don't think so, because it'll use the current timestamp.

I feel like it should be possible with some post-merge github action or something, but probs not worth setting up anything overly complicated.

Is there anything you think should get ignored? I looked at the blame for the abc file and the only ones I see are at least 4 years old.

Did a quick look and there's a bunch of recent PR's that are somewhat borderline, like #2930 and #2932. #2823 has a mix of blocks of reformatting and other stuff.
Not sure about #3024. #3044 definitely merits it.
Although I guess if people expect to use blame for debugging formatting/linter/typing errors and not for functionality there's a much weaker case for using .git-blame-ignore-revs at all - but of course you can ignore the ignore-revs file if you want a "raw" blame.

If we really wanted to we could split partial-reformatting PR's into two commits that we merge onto master, ignoring one of them, instead of squashing.