Keep the history you reviewed.
Keep the next task moving.
With Git, you choose between joining histories and replaying commits onto a new base. TOVIO’s native CLI gives you an everyday default: preserve the finished work, then update the eligible work that depends on it.
You start a feature. While you work, main moves forward. Your feature and the team’s new work now need to come together. Git gives you two different ways to do that.
Which policy does this repository use? What happens to the branches stacked above this one? Which hash still identifies the reviewed work? Neither Git operation is wrong. The repeated decisions and follow-up work are what TOVIO aims to take out of your day.
Git’s own guides: merge · rebase. Git platforms and stack tools can automate parts of this workflow.
TOVIO separates two jobs that often get tangled together: integrating reviewed work and updating unfinished work. The native CLI coordinates both through land.
tovio land payment-api --into mainShip the API lane. Keep building the checkout.TOVIO joins the API’s history with main, or fast-forwards when eligible. It retains the original source commits instead of recreating them just to flatten the graph.
The authorship and signatures belong to the same commits you reviewed.
The CLI rebases eligible dependent changes onto the new lane state. The form and UI get a current base; their stable Change IDs stay attached to the work.
Keep developing without a separate manual restacking routine.
A lane names a line of work, much like a branch. A change is an identifiable unit of work. The cascade is path-scoped: non-overlapping lanes can be left alone, protected lanes are never rewritten, and partial results are reported.
The payoff is practical: fewer dependent branches to repair by hand, original review evidence kept in history, and a stable name for work that moves.
| What you care about | Git | TOVIO |
|---|---|---|
| Keep the reviewed evidence | A merge retains the original commits. A rebase recreates them on a new base, with new hashes. | Default landing keeps the original source commits, with their authorship, signatures, and available agent provenance. |
| Spend less time restacking | Updating dependent branches is a separate task. Commands, hosting services, and stack tools can help automate it. | The native CLI land operation also rebases eligible descendants. Finish one piece without manually rebuilding the work above it. |
| Keep referring to the same work | A rewritten commit has a new hash. A pull-request tool may maintain a separate conversation around it. | A Change ID identifies the work separately from its commit hash. B remains B after a supported rewrite, even though its snapshot changes. |
TOVIO’s merge-aware history readers follow content back to the authoring work. An integration merge doesn’t have to take the credit for every line it brings in. That makes preserving the original commits useful, rather than a reason to sacrifice readable attribution.
See how change identity worksLess history maintenance should also mean less hesitation. Inspect a landing before it changes anything, then inspect the resulting stack.
tovio land payment-api --into main --dry-run --explainSee the merge base, per-file decisions, and gates without advancing a reference.
tovio undoWhen the landing is the next undoable operation, one undo restores it and its cascade. Local retention applies; undo cannot recall a result another peer has already observed or reverse external effects.
Merge and rebase remain mechanisms in TOVIO. The everyday dilemma matters less because the default handles integration and stack maintenance together.
Choose it explicitly with tovio land payment-api --into main --rebase. TOVIO recreates the source commits on the target, keeps their Change IDs, and signs the new commits as the lander. You trade preservation of the original landed commit objects for a linear mainline.
This option accepts one source lane and refuses a source that already merged its target in. Read the linear-landing rules.
No. Conflicting intent still needs a decision. In an eligible unprotected cascade, TOVIO stores the disagreement as a conflict object and continues with the remaining descendants. Both sides stay inspectable; this does not prove the code is correct or buildable.
Protected-lane conflict restrictions and other configured landing gates still apply. Understand conflicts as objects.
The automatic cascade described here is the native CLI workflow. It only rewrites eligible descendants in its path-scoped cascade; protected lanes are not rewritten. Inspect reported skips or partial results and follow the suggested next action.
Other clients and entry points have their own supported behavior. Consult the land guide for the workflow you use.
Evaluate TOVIO with a small stack: land the ready change, inspect the work above it, and follow the same Change IDs onto their new base.