[jjav]

Line count (or count of any units in the PR) is completely meaningless.

I feel that in the last decade somehow there has been a loss of context of what is the purpose of version control.

Why do we bother with version control? Sure, there are many reasons.

But a primary reason is that if we discover behavior X turns out to cause regressions (or is otherwise a bad idea), we can easily revert it by reverting its commit.

That's a why a single commit should contain a single behavior change, and contain the entirety of that single behavior change.

If the change is split among multiple commits, it'll be a pain to revert it. If the change is contained within a commit that changes other things, it'll be an ever larger pain to revert it.

So that's my rule. A commit is single behavior change, all of it, and nothing else.

You can't express that in lines. Might be 1 line might be lots.

[wubrr]

100% agree, if you have multiple commits to complete the change during development, just squash them into one for the PR.

That being said many companies (including some FAANG) use commit counts as a performance metric, thereby directly disincentivizing clean, readable commits.

[mandelbrotwurst]

Sure, and at the same time a PR can contain multiple commits. You don't have to squash and merge.

[wubrr]

I've rarely seen cases where multiple commits per PR are a good thing. When that happens, it's (usually) that either the commits can be squashed into one logical/consistent commit, or there are too many changes for one PR.

The exception being that many ci/cd setups will squash your commits for you when merging a PR.