@david_chisnall The formatting churn for clang-format is so horrible. In my C++ project where formatting is enforced with clang-format, I have the Makefile create a Python venv into which I pip install clang-format=18.1.8 (using pip as a cross-platform distributor of version-locked clang-format builds).

Contrast to Rust, where I just run `cargo fmt` on my laptop, my desktop and in CI and it's fine.

Formatting churn across versions in a code formatter should be considered a bug.

@david_chisnall https://github.com/llvm/llvm-project/blob/main/clang/tools/clang-format/git-clang-format would this help? IIUC it only formats what you changed.
If the 2 styles are too different from each other you'll end up with an inconsistent style in the file though.

If you do reformat the whole codebase then a merge driver could help [e.g. with outstanding PRs/branches) (it reformats all 3 sides of a merge, and is usually able to avoid conflicts most of the time that way) https://github.com/emilio/clang-format-merge.
(Or equivalently if you use `jj` there is a configuration option to autoformat each commit).
You can also define certain commits to be ignored by 'git blame', e.g. the reformatting commits.

I haven't tried this with clang-format, but the equivalent steps with `ocamlformat` work great (and we've done several repo wide reformats on version upgrades).