Dependent changes, each reviewable on its own

Each one shows only its own work

A stacked pull request diffs against its parent rather than the base branch. A reviewer opening the third change in a stack sees the third change, not the two below it repeated.

Merging the bottom retargets the rest

This is the part that decides whether stacks are usable. When the bottom of a stack merges, its branch is gone or about to be, and a child still pointing at it shows a diff against a branch nobody is updating.

Each child moves down to whatever its parent was based on, which is the branch its changes were always going to. A child that somebody retargeted by hand is left alone, and only loses the stale link to the merged parent.

Merging a layer lands what is under it

The instinct is to refuse a merge until everything below has landed. That is the wrong end of the stick: merging the third layer takes the second's commits along whether or not the interface admits it. So merging a layer lands that layer and every unmerged one below it, and says so before it does.

This is where GitHub landed too, in their stacked pull requests preview. Agreeing with the tools people already use is worth more here than being different.

Order is enforced, not suggested

A stacked pull request will not merge before its parent. Merging out of order would take the parent's commits along with it and leave the parent showing a diff of nothing, which is a mess that has to be untangled by hand.

Detected from the branch, not from a convention

Opening a pull request against another open pull request's branch is what makes it stacked. There is no naming scheme to learn and no metadata file to maintain.