Say hello to a long list of smallish commits full of random, unrelated changes and with commit messages "fixed various small issues", "continued implementing <feature>", etc
I'm good with that! It's faster, and easier, to review many smaller PRs, than one large one, IME. (Although also IME, in actual time, larger PRs get "reviewed" faster by not getting reviewed at all.)
(I'd want a better commit message than those, though. But they might just be examples for the sake of discussion.)
I tried to start getting people to follow a rule of "if it's a cosmetic/stylistic change, so long as it passes CI, +1". (Nowadays I work in a language what has a decent auto-formatter, and CI just runs & enforces that…) There's a whole slew of similar changes that fall under that umbrella, if you can have the test for it. (I.e., if I can encode my review into a program that CI runs … then yay! For PRs that meet that, if CI is happy I'm happy.)
Generally it's based on the feature / ticket in JIRA or whatever software you use. If the ticket is causing a commit with +8,298, -1,943, then we'd go back and break up the ticket itself into smaller tickets and then ask the coder to assign the changes to each ticket. There is no way we'd merge changes with such large file addition/deletions.
(I'd want a better commit message than those, though. But they might just be examples for the sake of discussion.)
I tried to start getting people to follow a rule of "if it's a cosmetic/stylistic change, so long as it passes CI, +1". (Nowadays I work in a language what has a decent auto-formatter, and CI just runs & enforces that…) There's a whole slew of similar changes that fall under that umbrella, if you can have the test for it. (I.e., if I can encode my review into a program that CI runs … then yay! For PRs that meet that, if CI is happy I'm happy.)