[user-the-name]

> Ideally, each commit should be something that you could submit as a stand-alone patch to a mailing list

Why?

[azernik]

Because when debugging with said history a week or a month down the line, or when someone else is debugging with said history, their human comprehension is essential for understanding why a certain event in the history is causing problems and what that event was intended to do.

[user-the-name]

That seems connected to the initial claim in only the most tenuous way.

[azernik]

In the Linux kernel mailing lists, which are the submit-by-email culture I'm most familiar with and with the best documentation of norms, the main criterion for individual patches is that they be comprehensible to a reviewer. Reviewers and bugfixers face similar reading comprehension constraints.

[user-the-name]

But why should any of that apply to my version control system? I'm not developing the Linux kernel on a mailing list.

[pdimitar]

It shouldn't for your personal stuff.

But it absolutely should when you work in a team. I'll personally scold you if you waste my time with merging a 20 commit PR of which 10 commmits are "fix stuff" or "fix typo" or "oops forgot variable" etc. It won't pass code review.

You are free to disagree. I am only telling you how it is in many companies.

[user-the-name]

But why? What problem are you actually solving with this?