I think it is conceptually the same but multiple PRs gives you the tools to manage the commits properly which GitHub is missing. You can't do the equivalent of `git rebase -i` in the GitHub UI to squash a fixup into a previous commit. Having each change in it's own PR enables that workflow using the existing GitHub UI.

Split into individual PRs, which works better for how a lot of companies do code review.

Stacked PRs track changes through updates and can be integrated progressively as they get validated.

They also allow reviewing commits individually, which is very frustrating to do without dedicated support (unless you devolve back to mailing list patch stacks).

It would be the same if commits were meaningful things. But typically they're not. The PR is the meaningful thing. A commit is something like "fix the lint error".

CI runs on each PR, you get a whole PR message and discussion/review interface for each PR. Each PR can itself consist of multiple commits. You can have stacked PRs from different authors (though from another comment it sounds like they may not have implemented that).

It's a big improvement (assuming they've done it right).

Each commit can be merged independently as they're reviewed.

I don't think this is it. The main driver is that several operations in GH are scoped around a PR, not a commit. So the reason you need stacked PRs is that the layer of tooling above `git` is designed to work on logical groups of commits called a PR.

Right, the argument against: "how is this any different than splitting into single commits?" is simply: In general you want just one level above a commit which is the PR

One of the advertised features of this is being able to merge all the PRs at once. Which would also be the case for multiple commits in a single PR.

That's possible but not mandatory. In the current UX you can only approve/submit all or none.

> Commits are immutable

I guess this is why you're getting downvoted. Commits can be edited.

When you edit a commit, it creates a new commit. They are immutable. You can still find the old commit via the reflog, until it gets eventually gc'd.

If I had to guess a reason they were downvoted (and I didn't downvote, to be clear), it's probably because people see stacked diffs as specifically solving "reviews clearly taking too long, too much content in there", and so it feels contradictory. Then again, as I said, I didn't downvote!

I agree with the sentiment but hash collisions can occur with different content which doesn’t really make them immutable.

Thank you for the correction.