tovio.DonateSign inEarly access

The model · change identity

Rebasing should not delete the review.

A commit hash identifies a snapshot of a tree. Teams use it to identify a unit of work — and then rewrite history, which is exactly the operation that replaces the hash. Everything anchored to it detaches. That is not a tooling gap; it is the wrong noun.

The trace

One unit of work, five operations, two kinds of identity.

TOVIO keeps both. The commit ID stays a content hash and keeps doing what a content hash is good at. The change ID names the work.

OperationCommit ID (content hash)Change ID (the work)
tovio committhe work is first recordedblake3:8c14f0a2…chg:4E1A08KQ
tovio commit --amenda typo in the same workblake3:2b90dd71…chg:4E1A08KQ
tovio rebasemoved onto a newer baseblake3:f5027cc9…chg:4E1A08KQ
tovio change absorba fixup folded into the change that owns itblake3:a71b3e40…chg:4E1A08KQ
tovio landadvances the shared laneblake3:d0c6819b…chg:4E1A08KQ

Illustrative identifiers. A change ID is a random 128-bit value rendered as chg:<base32> — deliberately not derived from content, so content can change without the identity moving. It stays stable across the supported rewrite operations.

Why it matters

Four familiar problems, one shared cause.

01

Review threads detach

A comment anchored to a commit hash is orphaned the moment the author cleans up the branch. The reviewer's context is real work that the tooling then throws away.

02

Automation loses the thread

CI results, risk scores, approvals, and agent provenance are keyed to something that history is expected to replace. Every rewrite is a cache invalidation nobody asked for.

03

“Is this the same change?” becomes a guess

Cherry-picks, backports, and stacked work are matched by patch text, subject line, or a trailer someone remembered to keep. All three are heuristics.

04

Rewriting becomes political

Teams ban rebasing to protect review continuity, then live with the merge noise instead. The rule exists because identity was attached to the wrong thing.

What it buys

Things that stay attached.

Once identity survives rewriting, a set of features stop being hard:

  • Review follows the work. A proposal tracks the change ID and a reviewed commit, so tidying the history before landing does not reset the conversation.
  • Provenance survives cleanup. Agent and task attribution stay on the change through amend and absorb — see agent fleets.
  • Undo is a first-class operation. A local op-log makes supported, retained mutations reversible with undo and redo.
  • Conflicts are durable objects. A conflict is stored, typed data that can be inspected and resolved later — not a state your working tree is trapped in.

Read this precisely

  • A change ID is stable across the supported rewrite operations. It is not a claim that any arbitrary history surgery preserves it.
  • A lane is a landing target, not a second identity for the work. Recording a change and advancing a shared lane stay separate operations.
  • Undo covers supported mutations retained in the local op-log. It does not recall peer observations or reverse external effects.

The concept, in the documentation.

The change model →Changes vs lanesRewriting historyComing from Git