Stacked PRs are now live on GitHub

> What's the benefit of this type of stacked PRs over a well-curated set of commits, and reviewing per commit?

For the people who work with stacked diffs (in phab/otherwise) this is exactly what they'd consider reviewing a well-curated set of commits one-by-one.

One distinction is that cognitively a unit of review (a PR, a diff) remains a single bound change. Comments are focused on that change and the PR does not grow with size of the feature

Another distinction is the ability to focus each part of the stack to a particular audience. One change may require review from an external team, another may be just your team mate, a third might be the consuming team. By focusing the stack to the different reviewers you can avoid ambiguity about "what a person is signing off on" in the stack.

aside: one thing that would be great for github reviews is the adoption of change ids such that comments persist across reviews with a rebase workflow.

I feel like many people (and industry in general) complicate things unnecessary.

  Stacked pull requests break large changes into small, reviewable pull requests. 

That's how pull requests are supposed to be, no? If yours aren't that - you ought to rewrite them.

  With stacks, you can independently review and check each pull request, then merge everything together in one click.

Why would I want to do that instead merging (and deploying/testing) separately, which gives me more reliability?

  No more opening a single large pull request that takes forever to review, or splitting work across multiple branches you have to keep manually rebasing.

Well, it doesn't seem like a simplification over dreaded "manual rebasing". And the target branch still moves, doesn't it? So, how are you "saved" from rebasing?

It's like responsibility is shifted from the author to the tool. That has been tried before, and every time it seem to consistently produce a similarly shaped mess in a different area of a process, but with an added bonus of the tool's own problems and restrictions.

Lol, maybe they should first fix large PRs crashing/freezing UI.

Started using the gh stack CLI when I first heard of this feature & really liked it - great tooling. Then got approved for the preview & found the corresponding web UI features incredibly underwhelming.

Pre-approval the CLI tooling effectively enables easier automations around splitting a task into multiple atomic PRs - really great locally but then when you push they just show up as independent unlinked PRs.

Post-approval... they still show up as independent PRs. There's a small nav drop down up top listing the other PRs in the stack but that's it. Literally no meaningful UI changes.

The dropdown also allows you to perform a limited subset if the CLI functionality but this is similar to the ability to edit files in the UI - an optional extra casual use feature that won't be a part of dev workflows: the CLI (or IDE plugins I guess) would be the primary way to perform these actions.

It all left me wondering what the big deal with the preview not being a general release - it's extremely minor optional UI. The stacks cli has been general release since this was announced.

With stacking you can continue working on a longer change while creating reviewable diffs. Merged diffs can be rebased on your HEAD. For teams that support stacked diffs you don't usually even need to manage branches and work directly off trunk and rebase changes as they come in