Stack a proposal on top of another
change propose --onto, for work that depends on a review still in flight.
Written By Dustin
Last updated About 3 hours ago
tovio change propose <chg-id> --onto prop:<parent-id> --remote <host:port>Bases this proposal on an open parent proposal rather than on the target lane's tip. Use it when your work depends on a change that is still in review and you do not want to wait, or to split one large change into a readable sequence.
What the Forge does differently
- It reviews only this change's delta over the parent, so reviewers are not shown the parent's diff again.
- When the parent lands, it retargets this proposal onto the lane automatically. You do not rebase and re-propose by hand.
Why the Change ID makes this work
A stack in Git is fragile because rebasing rewrites commits and the review loses track of them. TOVIO's Change IDs are stable and survive re-derivation, so amending or rebasing a member of the stack keeps its proposal attached rather than orphaning it.
What still applies
Stacking changes the base, not the gates. Every land gate is evaluated for your proposal in its own right — approval counts, reviewer eligibility, required checks, and protected-path read coverage.
Coverage in particular is worth knowing about here: it is computed over the whole-tree diff from the pinned base to the pinned commit, so a protected path introduced by a parent in the stack is caught when your proposal lands, even though your own change never touched it. That is deliberate — the gate asks what advancing the lane would newly place on it, not what you personally edited.
Practical shape
- Propose the bottom of the stack normally, against the lane.
- Propose each subsequent change with
--ontonaming the proposal below it. - Get them reviewed in any order; land bottom-up.
- As each parent lands, the ones above it retarget themselves.
When not to stack
If the changes are genuinely independent, propose them independently — a stack couples their landing order for no benefit. If the parent is likely to be rejected outright rather than revised, the work above it inherits that risk.
Splitting instead of stacking
If you have one change that should have been two, split it before proposing rather than stacking after:
tovio change split <chg-id> --paths 'src/api/**'That carves the matching files into a landable sub-change and leaves the rest stacked on top of it, keeping the original Change ID on the remainder.