# 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. A Git mirror that `zit serve` serves keeps importing after its
first clone. `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 served Git mirror keeps importing
`import-git --into` and `zit info --imported-head` compared the store's
artifact count with the count recorded at the last import, and refused
on any difference. Anything else that wrote to the store stalled the
mirror for good: `--into` refused `map_stale` and `--imported-head`
refused every time. `zit serve` itself does that write. The first pull
or clone a client makes from a freshly imported store mints cluster
artifacts, so any mirror served for sync stalled after its first
clone. A forge's wiki pages, tickets and tags did the same.
Both checks now read what was added since the import. Clusters, wiki
pages, tickets, technotes, forum posts, attachments and tags leave the
map valid, and the next `--into` records them. A check-in the import
did not write, or a control artifact that moves a check-in to another
branch, is still divergence and still refused. A mirror already stuck
on clusters or such artifacts imports again with 0.7.5, with no repair
step.
## 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](RELEASE-NOTES-0.1.0.md).