I think you are arguing against an extreme version of the practice. Normal advice is to shoot for 100-200 lines in a commit, not split that into ten commits th

I think you are arguing against an extreme version of the practice. Normal advice is to shoot for 100-200 lines in a commit, not split that into ten commits that each change 15 lines. If someone is splitting 100-line commits into 10-line commits, I would advise not doing that. However the direction that people normally err (IME) is submitting 500-2000-line commits which conflate multiple atomic changes. I would also advise not doing that. It’s easier to review a sweet-spot commit, and it’s easier to understand when you later have to debug/bisect a change set. Another related concept is to try to split “functional no-op” refactors from behavioral changes. This is usually the first and easiest way of getting your commit size down, as refactors often bloat the diff. In your example case I’d hope you have UTs exercising each chunk that is added. There are sensible APIs to shape at granularities smaller than the whole feature (model, service, etc) (or should be at least). If you really can’t add a new endpoint without a 1k- line PR I think you might need a new abstraction layer. But often you can add a new endpoint in meaningful chunks that are feature-flagged off, if you craft it thoughtfully.