I've long held the belief that it's always possible to write perfectly readable medium, even large sized PRs that are super reviewable if you abide by the following two simple rules:
- Use small, logical commits
- Review commit by commit
This approach works phenomenally well. Small commits allow easy isolation of changes, and those in turn make reviewing each commit a breeze because they're all small and focused.
For some reason, GitHub wants to make the latter experience awful and insist on all reviews always running through the files tab. Because when I think of logically grouped changes to review, I totally think of just all the files at once in alphabetical order.
GitHub has its problems. Actions is better measured by its unexpected uptime, it continues to force code review through alphabetical file order, and former Facebook employees have ruined countless work lunches complaining that GitHub isn't phab doesn't have stacked PRs.
But now stacked PRs are here! And so many people are abusing the shit out of them. I don't deny there are use cases for them, I use them myself. But I've seen incomprehensibly tall PR stacks and I'm sorry but there is no way you have 15 changes that must be merged serially. Not only is it 15x the overhead, it's also 15x the CI and 15x the code reviews. To what end?
PR stacks should be an exception rather than the norm. And when you need to reach for one, I'd argue the max height should be like... 5? And even then only if it's a really meaty change?
Thank you for reading,
-an exhausted code reviewer