If you regularly need to review 10000 lines of code per PR your dev workflow is seriously broken. It‘s got nothing to do with git and its implementation‘s complexity.

Sometimes features do require large changes. But usually you can break a feature into different parts (e.g. database, backend, frontend) and merge them in separately.

Not regularly, no. But sometimes a feature change requires a dependent architectural change — a refactoring of the internal library code that the feature will be implemented in terms of. Or sometimes an upgrade of the auto-formatter dependency means that some things gets reformatted. And sometimes, a dev thinks it's a good idea to change the format of a data file or embedded data-structure literal at the same time that they're adding an entry to it.

> But usually you can break a feature into different parts (e.g. database, backend, frontend) and merge them in separately.

So you've already written all that code, because you couldn't get anything to "work" for end-to-end testing until you wrote all parts of it. The patchset as a whole is inherently large.

Now what? How do you "break [the] feature into different parts" when it's already all written and committed on a WIP branch?

That's right: cherry-picking and rebasing.

The GP is arguing against bothering with this process. Presumably because git-rebase(1) is unintuitive to them, and they don't realize that you should start this workflow with a copy of your branch, or a new branch with cherry-picked commits from your WIP branch, to guarantee non-destructive rebasing. Like making a copy of a layer in Photoshop. (Yes, you can always restore your branch from the reflog, so it's technically always non-destructive; but `git checkout -b foo` is something you learn in Chapter 1 of the Git book.)

Nobody should have long running WIP branches with these massive commits full of unrelated stuff. That’s an antipattern.