- This causes conflict for all other concurrent PRs. Which could be dozens or even hundreds.
This problem can be solved by a little thing we call “coordination”, aka “talking to each other”.
If you want to make large-scale changes like this, you will need to stop everything else you are doing. This might sound scary at first, but consider this: it only takes one second to check out the code, run the formatter, commit, and push it.
The important thing is to make sure that you don’t get held up doing this. If you have code review procedures in place, make sure they don’t get in the way.
You don’t have to review the commit. Instead, what you do, is to beforehand review the formatter and its options. You need to convince yourself that running the formatter cannot possibly break anything. Review the heck out of it, run it in parallel for a couple of months (run the test suite on your current code, run the formatter, run the test suite again, do that for as long as you need to convince yourself on every single commit), ask fellow developers for their experiences, etc.
Make sure that the exact version and the exact settings for the formatter are part of the commit message of the commit that introduces the change. This allows every developer to reproduce the commit to ensure that you didn’t sneak in any changes together with the formatting changes.
- This complicates
git blame. It is often useful to walk back through history of a given line and see where it was changed and why, but if the formatter touches say 30% of the lines suddenly you have to step over it and rework things out when tracking history of a line.
This one, unfortunately, is not avoidable, unless you have some sort of semantic diff or semantic blame tool that understands the semantic structure of the code, and doesn’t just stupidly treat it as a dumb array of characters.