Small reviews allow moving faster for both the author and reviewer.

A chain of commits:

* Does not go out for review until the author has written all of them

* Cannot be submitted even in partial form until the reviewer has read all of them

Reviewing a chain of commits, as the reviewer I have to review them all. For 10 commits, this means setting aside an hour or whatever - something I will put off until there's a gap in my schedule.

For stacked commits, they can go out for review when each commit is ready. I can review a small CL very quick and will generally do so almost as soon as I get the notification. The author is immediately unblocked. Any feedback I have can be addressed immediately before the author keeps building on top of it.

Let's compare 2 approaches to delivering commits A, B, C.

Single PR with commits A, B, C: You must merge all commits or no commits. If you don't approve of all the commits, then none of the commits are approved.

3 stacked PRs: I approve PR A and B, and request changes on PR C. The developer of this stack is on vacation. We can incrementally deliver value by merging PRs A and B since those particular changes are blocking some other engineer's work, and we can wait until dev is back to fix PR C.

Historically, hn etiquette is that it's fine to downvote for disagreement. This came from pg himself.

That said, while he hasn't posted here for a long time, this is still in the guidelines:

> Please don't post comments saying that HN is turning into Reddit. It's a semi-noob illusion, as old as the hills.

https://news.ycombinator.com/newsguidelines.html