zit

A Fossil version-control system in Zig.

zit reads and writes Fossil's artifacts and speaks Fossil's sync protocol, so it clones from, pushes to, pulls from, and serves stock fossil, and a checkout means the same thing to both tools. It is written from the specifications, not ported from C: six Internet-Drafts frozen in this repository are the authority, and Fossil itself appears only in the differential tests that hold the two implementations to the same answer.

The zit binary is a thin command over a library — a Zig counterpart to libfossil — whose modules take no ambient time, randomness, filesystem, or network, so the whole stack runs under seeded deterministic simulation.

Download

Download Zit 0.3.8 for macOS ARM64 or Linux x86-64/ARM64, or get the source archive, or read the release notes.

Releases are also mirrored to GitHub.

What it does

The everyday verbs — init, add, commit, update, merge, diff, status, timeline, branch, tag, annotate, grep, bisect, stash, undo/redo, clone, push, pull, sync, serve — with Fossil's output shapes and Fossil's settings: .fossil-settings/ is read at every tier, ignore-glob, clean-glob, manifest, and the rest mean what they mean in Fossil.

Beyond that:

• Git in both directions — import-git and export-git.
• Sub-manifests — bounded per-commit manifest size for wide repositories (submanifest analyze / enable). Off by default; a repository that turns them on is no longer readable by stock Fossil, and sync refuses to hand such artifacts to a peer that would misread them.
• Sparse cones — partial worktrees (open --cone, cone).
• Indexer feeds — frames and crosslink stream raw artifacts and derived per-check-in records from a cursor, for a forge or search index.
• Store care — verify, pack, purge, shun, and a local rebuild checkpoint that keeps cache-cold opens fast on large histories.

What it leaves to Fossil

By decision, not omission. The collaboration artifacts — wiki, tickets, forum, technotes, attachments — are stored and synced by hash but never interpreted, and the web UI goes with them (zit ui hands off to a forge that serves the repository). There is no unversioned-file store; a peer's unversioned files are declined visibly. zit never signs a manifest and never creates a SHA-1 repository, though it reads both.

The specifications

The drafts under docs/rfcs are the sole authority. Expected values in tests come from the spec text and its worked examples, never from observing another implementation; where the code follows Fossil's implemented behaviour against the published text, the divergence is recorded in docs/rfcs/erratum.

Each layer depends only on the layers before it:

boxwid = 1.1in; boxht = 0.45in; movewid = 0.45in
D: box "delta" mono fit
arrow
A: box "artifact" mono fit
arrow
R: box "repostate" mono fit
arrow
S: box "sync" mono fit
M: box "submanifest" mono fit at A.s + (0.55in, -0.8in)
arrow from A.s down 0.25in then right until even with M.n then to M.n
arrow from M.e right until even with S.s then to S.s
C: box "cone" mono fit at R.s + (0.55in, -0.8in)
arrow from R.s down 0.25in then right until even with C.n then to C.n
arrow from C.e right until even with S.s then to S.s

That ordering is also the implementation order, and src mirrors it module for module.

Building

Requires Zig 0.16 or later.

zig build --release=fast   # the shipped binary, at zig-out/bin/zit
zig-out/bin/zit version
zig build test             # unit tests, one cited test per RFC clause
zig build smoke            # interop check against a fossil binary on PATH

--release=fast is what the release builds use; a plain zig build is a Debug binary, many times slower on a real history.

Finding your way

• Timeline — current activity and history
• Source tree — browse the code at trunk
• README — design notes, scope, and build steps
• Release notes — every release, oldest to newest
• docs/rfcs — the six frozen drafts
• GitHub mirror — issues and CI