The reviewable unit being as atomic as the version control unit has many positive knock-on effects. For example, if you merge numerous commits and keep the commit information, often times you will wind up with commits that have partial or complete breakage, which can seriously be a pain when someone is trying to triage a regression, for example.
There is not one exact correct philosophy about how small the atomic unit is or what constitutes too much work, but the general wisdom is something to the order of "do one thing."
I believe a PR should "do one thing," so PRs with multiple commits should be safe to flatten, else they likely contain too much. Of all of the things Google is rightly criticized for, their methodologies towards code review are pretty good and this is more or less what it felt like working in pseudo-Perforce. What if you needed multiple changes? Well, it was certainly more cumbersome than needed, but serieses work great here. Not only that, but patch serieses are already well established in the software engineering canon! Plenty of projects have accepted patch serieses over mailing lists for decades.
I know many people have seen Github-style workflows work pretty well and so are unlikely to be receptive to the idea that some of the fundamentals could be wrong, but my advice is please consider it. It's not like there's one exactly correct way to handle merging changes, but I've found that the process of focusing on atomic sets of changes individually has improved my discipline as a software engineer. It may be a bit too wanky to call it "enlightening," but it's pretty close.
There is not one exact correct philosophy about how small the atomic unit is or what constitutes too much work, but the general wisdom is something to the order of "do one thing."
I believe a PR should "do one thing," so PRs with multiple commits should be safe to flatten, else they likely contain too much. Of all of the things Google is rightly criticized for, their methodologies towards code review are pretty good and this is more or less what it felt like working in pseudo-Perforce. What if you needed multiple changes? Well, it was certainly more cumbersome than needed, but serieses work great here. Not only that, but patch serieses are already well established in the software engineering canon! Plenty of projects have accepted patch serieses over mailing lists for decades.
I know many people have seen Github-style workflows work pretty well and so are unlikely to be receptive to the idea that some of the fundamentals could be wrong, but my advice is please consider it. It's not like there's one exactly correct way to handle merging changes, but I've found that the process of focusing on atomic sets of changes individually has improved my discipline as a software engineer. It may be a bit too wanky to call it "enlightening," but it's pretty close.