[Arainach]

Looking at multiple commits is not a good workflow:

* It amounts to doing N code reviews at once rather than a few small reviews which can be done individually

* Github doesn't have any good UI to move between commits or to look at multiple at once. I have to find them, open them in separate tabs, etc.

* Github's overall UX for reviewing changes, quickly seeing a list of all comments, etc. is just awful. Gerrit is miles ahead. Microsoft's internal tooling was better 16 years ago.

* The more commits you have to read through at once the harder it is to keep track of the state of things.

[Hamuko]

>It amounts to doing N code reviews at once rather than a few small reviews which can be done individually

I truly do not comprehend this view. How is reviewing N commits different from/having to do less reviews reviewing N separate pull requests? It's the same constant.

[Arainach]

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.

[tcoff91]

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.

[mike_hearn]

> You must merge all commits or no commits

This seems to be the root of the problem. Nothing stops a reviewer merging some commits of a PR, except a desire to avoid the git CLI tooling (or your IDE's support, or....). The central model used in a lot of companies requires the reviewee to do the final merge, but this has never been how git was meant to be used and it doesn't have to be used that way. The reviewer can also do merges. Merge (of whichever commits) = approval, in that model.

[tcoff91]

Yes, the root of the problem is the workflow of the company being centered around GitHub instead of Git itself.

This feature helps improve GitHub so it's useful for companies that do this this way.

At our company, only admin users can actually directly git push to main/master. Everything else HAS to be merged via github and pass through the merge queue.

So this stacked PRs feature will be very helpful for us.

[tcoff91]

It's crazy that you're getting downvoted for this take.

This isn't reddit people. You're not supposed to downvote just because you disagree. Downvotes are for people who are being assholes, spamming, etc...

If you disagree with a take, reply with a rebuttal. Don't just click downvote.

[steveklabnik]

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

[tcoff91]

Well, I stand corrected.