[degenerate]

Lines with actual code changes aren't a problem for me, it's the automated IDE indent/spacing/bracketing that really drives me up a wall and fatigues the hell out of me.

But this might only be a problem with those of us working on legacy codebases. The kind of PRs I see in OSS projects I could review 1000 lines at a time - it's so clean!

[joshka]

Split the reformatting and real change. Make the reformatting change first and have a policy of merging those change fast.

[degenerate]

Some teammates agreed to do this, but it's not known what files will be edited ahead of time, so a large job often has formatting edits anyway.

[joshka]

Yeah, it's really something that you have to get buy-in for.

You could always make a commit that just has the reformatting when you do start editing a file. If it turns out you didn't need to edit that file after all, then you can revert just that commit easily. And if you did, you can collect up all the reformatting commits into a PR as a first step.

The flip side of this is making minimal surgical small changes, and then doing the refactoring after the change. The key message though is split them.

Refactoring doesn't change behavior, so refactoring efforts should be judged only on "tests exist that cover the functionality, those tests continue to pass, the code is easier to maintain". It's when you add "changed functionality, so we changed the test" to review at the same time, that this becomes a hassle.