Stacks

Stacked pull requests, read in the order they were written.

Q: Does "blocked by #123" in a description count as a stack?

Never. A sentence is not a dependency. Text like "blocked by #123", "part of", or a pasted link appears under Related changes — useful context, kept deliberately apart from the ordered chain. PR Flow only calls something a stack when the provider says it is one.

See each layer's position, review the chain from trunk to top, and keep every layer's own Needs you, Waiting on others, or lower-priority state visible.

Download free Read the docs

Small PRs, big coordination cost

Small layers still need a visible order.

A stack is easier to review when the base layer, current layer, and next layer are explicit.

The order is invisible

Activity order can put an upper layer before its base. A position marker exposes that before you open the review.

Every provider models it differently

PR Flow labels the evidence used for each chain: provider data, branch relationship, commit ancestry, or an explicit inference.

Reviewing the wrong diff

The review header names the current layer and the changes included in its diff.

Guesswork dressed up as structure

Description links remain Related changes. They are not silently promoted into stack layers.

One journey, four providers

Position on the row, a map in the detail, a pager in the review.

Feed and Board

Every layer carries its place in the chain.

A neutral 2/4 marker sits beside the branch. Adjacent layers group visually while each keeps its own attention reason and unread state.

Position markers on the row, before you open anything
Adjacent layers of one stack grouped together
A filtered-out sibling is announced as “2 more in stack”

2/4 2 more in stack

PR details

The whole chain, trunk at the bottom.

Open a layer to see the chain from trunk to top, its review states, the current layer, and where stack membership came from.

A layer PR Flow already tracks opens in place
Every map names its evidence — native, branch chain, ancestry, or inferred
Loose references stay under Related changes, never as layers

Review

One layer at a time, with the stack still on screen.

A Layer 2/3 pager stays in the review header. Move between layers without losing the chain or confusing which layer receives the review.

A warning when a lower layer moved and this one may need a rebase
Submitting applies to the layer you are on, and says so
PR Flow offers the next layer; you choose when to open it
Comments stay staged until submit; merging remains your action

Layer 2/3 foundation changed approve this layer

Filters → Stacks

Work through your chains, or get them out of the way.

Filter to stacked work, hide it, or choose a named chain. The filter stays visible while active so it cannot hide its own control.

The section appears when the board contains stacked work
Show stacked, hide stacked, or select a chain

Provider truth only

Provider evidence stays visible.

Every map names the evidence behind its order. Related links remain separate from confirmed layers.

GitHub — native stack

Native stack data is shown in the order returned by GitHub.

GitLab — branch chain

Open merge requests are chained by their source and target branch relationship.

Gerrit — relation chain

Commit ancestry comes from Gerrit's relation chain. Topic links stay separate.

Azure DevOps — inferred, and labelled

Branch-based inference is labelled as inferred rather than provider-confirmed.

A sentence in a description is not a dependency

blocked by #123, part of, and pasted links appear under Related changes, not as stack layers.

When PR Flow doesn't know everything

Partial knowledge, shown as partial.

Missing layers, partial totals, stale maps, and inferred chains are labelled in the UI.

Turn stack features off in Settings → General to remove markers, maps, and layer navigation while keeping Related changes. Team policy can manage the same switch — see pricing, or the stacked pull requests documentation.

A layer you do not have access to keeps its row and says it is not visible to you
A stack longer than PR Flow can show reads “of at least 6” rather than claiming a total
If the provider cannot be reached, the last map is marked stale with Retry

Stacks are one layer of the queue, not the whole thing. The same board ranks GitHub pull requests, GitLab merge requests, Gerrit changes and Azure DevOps pull requests by what needs you next.

Questions

How stacks actually work here.

Do I need a stacking tool like Graphite or spr?

No, and PR Flow does not replace one either. It reads the stack your provider already knows about, whichever way you created it — a GitHub stack, merge requests chained by branch on GitLab, a Gerrit relation chain, or plain branch-on-branch work. If a stacking CLI is what produced those pull requests, PR Flow simply sees the result.

Can PR Flow create or restructure a stack for me?

No. Stack support shows you the order and lets you review along it; it never creates a layer or restructures a chain. Merging, rebasing or updating a layer is a separate action you take on one of your own pull requests at a time, confirmed against the provider first.

Does a stack become one big review?

No — that is the failure mode the feature exists to avoid. Every layer keeps its own place in Needs you, its own reason for being there, its own unread state and its own review. Submitting applies to the layer you are on, and the confirmation says which one. A finished lower layer never drags an unrelated review back into your queue.

Does "blocked by #123" in a description count as a stack?

Never. A sentence is not a dependency. Text like blocked by #123, part of, or a pasted link appears under Related changes — useful context, kept deliberately apart from the ordered chain. PR Flow only calls something a stack when the provider says it is one.

What happens on GitHub Enterprise Server, or an older GitLab?

Nothing breaks. GitHub's stack fields are still in public preview, and a server that does not expose them would reject a query asking for them — so PR Flow probes once, remembers the answer, and retries without those fields. On a server with no stack surface at all you simply get no stack: no markers, no map, no error banner, and every other part of the board unchanged.

Does this slow the board down?

No. On GitHub the position marker rides along on the poll the board already makes, so it costs nothing extra. GitLab and Gerrit resolve a chain when you open a pull request, cached for five minutes and refreshed in a small bounded background pass. Azure DevOps makes no extra request at all. If you would rather not have any of it, one switch in Settings → General turns it off.

Pull request dashboard

One ranked queue for pull requests spread across repos and providers.

Pull request review queue

How PR Flow decides which review needs you next, and why that beats a feed.

GitHub pull request dashboard

Review requests, your own PRs and stale threads on GitHub, in one queue.

Gerrit code review dashboard

Gerrit changes, patchsets and review labels alongside your other work.

Azure DevOps pull request dashboard

Azure DevOps pull requests ranked by whose move it is, with required and optional policies kept apart.

Reading

From the blog

How to Review Stacked Pull Requests When the Base Moves

In a stack, an upper layer's diff can stay the same while the code under it changes. What to recheck when a lower layer gets fixes, main moves, or the bottom merges.

Why Pull Requests Sit for Days Between Reviews

A PR can take twenty minutes of real review and still take a month to close. Where that time actually goes, and why AI widened the gap instead of closing it.

v1.23 · macOS · Windows · Linux

Review the stack one layer at a time.

You still review and merge each layer. PR Flow keeps the order and current layer visible. Try it free for 7 days; a one-time licence keeps it after the trial.

Download free See pricing