Export TOVIO history back to Git

The one-shot export, and exactly what is lossy about it.

Written By Dustin

Last updated 30 minutes ago

tovio git export /path/to/new-git-repo

Creates a fresh Git repository from TOVIO history. The target must be an empty or new directory — an existing repository is never clobbered, and a promisor-backed partial clone is refused because it cannot translate content it does not hold. This is an exit path and an interoperability tool, not a sync mechanism: for ongoing two-way work, use the bridge.

What survives

  • Commit history and topology, lanes (as refs/heads/*), and file contents including large binaries.
  • Author identity.
  • Change ids and agent provenance, as commit-message trailers — Tovio-Change-Id:, Tovio-Agent-Token:, Tovio-Agent-Model: and Tovio-Task-Id:. A TOVIO import reads them back, so a change id preserved as a trailer is recovered on the return trip rather than re-derived.
  • Submodules, back to Git's 160000 gitlink mode, with .gitmodules still the separately tracked authority for Git tooling.

What is lossy

  • Protected paths export as ciphertext. Git has no concept of per-file encryption, so a policy-covered file leaves as the encrypted bytes it is stored as, never decrypted. This is the correct behaviour and the most surprising one.
  • Tags do not export. The export writes lanes as refs/heads/* and nothing else — no refs/tags/* is created, even though import brings Git's tags across in the other direction. If your release tags matter, record them before you export and re-create them on the Git side.
  • Conflict objects are skipped. A materialized conflict is not file content, so it has no Git representation at all. Resolve conflicts before exporting or those paths simply will not be there.
  • Policy and rationale. The signed policy objects, the attested "why" behind a change, and the audit chain have no Git equivalent. Only what fits in a trailer survives.
  • The audit chain. Export it separately if you need it.

When to use it

Leaving TOVIO, handing a snapshot to someone who will never install it, or publishing a mirror. For anything ongoing, the bridge is the right tool — it uses the same translation underneath, so the two never disagree about what a commit becomes.