zit 0.7.5

zit 0.7.5 imports Git history about five times faster than 0.7.4, and the memory it needs for the whole Linux kernel is roughly halved. import-git takes a bare clone and reports progress through every phase. zit config pull interwiki fetches a Fossil server's interwiki map, so a mirror resolves TAG:path links. A horizon store refuses a pull for history it does not hold, rather than answering with less.

This release is from trunk. A store that has pulled or imported the interwiki area holds a new kind of record, and an older zit cannot open it; every other store is unchanged from 0.7.4.

import-git is about five times faster

Measured on the first 29,792 commits of the Linux kernel (a 2.5 GB fast-export stream, 97,015 blobs) on an Apple M4 Pro with 14 cores:

	0.7.4	0.7.5
Wall time	597 s	about 120 s
Store size	201 MB	177 MB

The import now writes the published store in one pass. Blobs wait for the commit that names their path and delta against the previous blob there; tree nodes delta against the node they replace. There is no raw generation to repack. Delta search and compression run on worker threads, blobs are read by parallel readers alongside git fast-export, and blob writes overlap the next commit. The verifier sweeps whole delta trees in parallel, and the repository cache is warmed on the worker pool after publication.

--threads N writes the same bytes for every N. The store is the same set of artifacts with the same content as 0.7.4 writes; the deltas between them differ, which is where the smaller size comes from.

import-git needs about half the memory at kernel scale

Three tables grew with every commit and blob. The cache warm-up now writes its body to the cache file as it builds it instead of holding it. The ingest tables keep an array indexed by mark and one record per blob, so ingest grows by 1,324 bytes a commit, down from 2,165. The verifier reads its witness and the import map back from the staging directory a window at a time; its peak falls from 4.07 to 2.07 KiB a commit. Projected from 10,000- and 30,000-commit slices, the whole kernel's 1.5 million commits need about 3.3 GB at the verify peak, where they needed about 6.2 GB.

The witness spill file is authenticated with a per-run key, and each record read back is checked, so a file changed during the run fails the verification rather than passing it.

The work is recorded in the technote "import-git: five times faster, half the memory".

import-git takes a bare clone

The source may now be a bare repository, such as a git clone --bare or --mirror, as well as a working tree.

import-git reports progress after ingest

Verification, publication and the cache warm-up each print progress, so a long import no longer falls silent after its last commit.

zit config pull interwiki

Fossil keeps an interwiki map: each TAG names a base URL, so a wiki or check-in comment can link TAG:path. zit config pull, import, merge and export now take the interwiki area. A pull sends reqconfig /interwiki and receives one config /config card per tag, exactly as fossil configuration pull interwiki does. zit serve answers the same request from its own rows, to any user with Read, and /all now includes the area.

A pull merges by default: a row replaces the one held only when its mtime is newer. --overwrite takes every row the peer offers. A tag the peer no longer offers is kept either way, as Fossil keeps it. A row with no base, or a tag that is not letters and digits, is skipped.

The rows are kept in the store as a new kind of record, a setting frame. The format, and what it means for older readers, is recorded in the technote "Stores keep Fossil's interwiki map".

A horizon store refuses a pull it cannot answer

Section 6.4 of the horizon draft says a horizon store must refuse a pull for a held set it does not contain. zit serve answered such a pull at an earlier C instead, so a client could believe it held history that it did not. It now refuses with an error card beginning horizon-not-held:, before anything in the request is stored, and zit pull quotes the refusal: zit pull: the peer refused: …. A pull naming a C the store does not hold at all comes from a peer ahead of it, and is still served.

A delta manifest's files no longer carry old renames

A rename marker on a file means it had another name in this check-in's parent. When zit expanded a delta manifest into its full file list, files inherited from the baseline kept the baseline's markers, so every later check-in claimed the same rename again. import-fossil --submanifest and tree building wrote those markers into the trees they built. A reader that computes per-check-in changes, as Fossil's mlink does, then recorded each of those files as added.

An inherited file now carries no marker; a delta's own renames and a baseline manifest's own renames are unchanged. Stores already reborn with --submanifest keep the stale markers in their trees; rebirth them again to drop them.

Smaller fixes

• zit extras, add and clean stop at a nested zit or Fossil checkout, as Fossil does. Naming the nested checkout itself still walks into it.
• zit landing settles an open landing from the merge that took its branch into the target, so a branch merged from a clone that never replied can be proposed again.
• zit serve answers reqconfig /config with one config card per setting, as the sync draft's Section 9.3 sends them, and a pushed configuration applies every card it carries. A push still needs Admin for every card.

Tested against stock Fossil

The smoke suite now has 32 scenarios. S31 pulls the interwiki area from a stock Fossil server, and has stock Fossil pull it back from zit serve. S32 has stock Fossil make a rename followed by delta check-ins, converts it with import-fossil --submanifest, and checks that the rename is claimed by the renaming check-in only.

Known limits

The whole Linux kernel history has not yet been imported with this release. A run on a build from before the memory work reached 99.8% of its 1,503,488 commits in about nine hours under an 8 GB limit, then stalled re-reading the store with no memory left to cache it. The projection above says 0.7.5 needs well under that, but it is a projection. The checkpoint file an import resumes from is still read whole and is limited to 4 GB.

zit config pull interwiki adds and updates tags but cannot remove one, so a mirror keeps a tag its upstream has deleted.

Compatibility

A store that has pulled, imported or merged the interwiki area holds setting frames, and zit 0.7.4 or earlier refuses to open it. Upgrade every zit that reads such a store, including a server that serves it, before pulling the area into it. A store that never takes the area is unchanged, and earlier releases open it as before.

On the wire, zit serve now answers reqconfig /interwiki, and the /all group includes it. A horizon store refuses a pull for a held set it does not contain with a horizon-not-held: error card; a client matches that prefix. A 0.7.4 client reports the refusal as a protocol error.

Qualification

The release manifest records native qualification against the exact tagged source archive on macOS ARM64, Linux x86-64 and Linux ARM64, using the pinned Zig 0.17.0 toolchain. Publication is gated on unit and end-to-end tests, Git differentials, deterministic simulation, seeded fuzzing, and Fossil interoperability checks on every distributed target.

For the basis of the conformance claim, see the 0.1.0 release notes.