Switch lanes without losing uncommitted work

tovio switch feature-xtovio switch chg:a3f7b2      # a change id works here tootovio checkout feature-x     # git-compat aliastovio checkout -b new-lane   # create and switch

Dirty work comes with you

switch performs a safe three-way materialization and never discards uncommitted edits. There is no "your local changes would be overwritten" refusal and no need to stash first. Tracked edits are carried onto the destination tree; ignored and untracked files are left alone.

The confirmation line tells you exactly what happened:

Switched to lane feature-x  blake3:715fac98ef…  materialized working copy · 3 carried change(s) · 0 conflict(s) · undo with `tovio undo`

If your edits and the destination both touch the same lines, the count on the right is non-zero and you get conflict objects — a normal, recoverable state where your tree still builds — rather than a blocked switch. tovio conflicts lists them.

Switching to a change

tovio change switch chg:a3f7b2

Materializes a specific change by its stable id rather than a lane. A bare tovio switch recognises an argument beginning with chg: and routes to the same place, so either spelling works.

It is one transaction

The materialization is journaled: files stage and roll back together, so an interrupted switch leaves the working copy on one side or the other, never half-way. On a sparse checkout only in-cone paths are written to disk — out-of-cone subtrees are carried by reference and never re-hydrated.

What can go wrong

• TVO-CLI-006 — no live lane by that name. Check tovio lane.
• TVO-OP-006 — a chg: id no commit in your history carries. Sync first if it is a teammate's.

Note that only an argument spelled with the chg: prefix is treated as a change. A bare base32 body is read as a lane name here, so it comes back as TVO-CLI-006 rather than switching to the change you meant.

If a switch went wrong

tovio undo

A switch is recorded in the op-log like anything else, and reverses in one step.