Artifact 72711b6379cca26612ac22c927f6e9d6339925fa292bac23fdd868c2e32a3a82:
- File
docs/RELEASE-NOTES-0.3.4.md
— part of check-in
[9033c13f21]
at
2026-09-17 17:04:25
on branch trunk
— Remove issue-tracker numbers from source and documents
The tracker is disposable and does not live with the source, so a number is a dangling pointer. Every zit#NN and #NN reference in code comments, test names, help text, smoke labels, identifiers, release notes and errata is replaced by enough context to stand alone, or by a short plain statement of the problem. No behaviour changed. (user: dmestas, size: 2562) [annotate] [blame] [check-ins using]
# zit 0.3.4 zit 0.3.4 is a crash fix. In 0.3.3 and earlier, `zit info` with no NAME segfaults on any repository whose history holds two check-ins with the same `event.mtime` — three merges landed within one millisecond is enough, and a repository that grows such a pair starts crashing without any change to zit. Every 0.3.3 install should take this. ## The crash The listing order's exact-mtime tiebreak compares full artifact hashes, and read them straight from the raw artifact store. Verbs on the zero-parse image path (`.fast_read` — bare `info` among them) carry the hashes in the image's own pool; their raw store is an empty placeholder, so the tie comparison read through an entry that was never populated. In a release build the only guard is a Debug assertion, which is compiled out: SIGSEGV. The same query under `zit timeline` opens the full derive and never crashes, which is what made the failure look random. Five ordering tiebreaks had the same raw read — the timeline order, the tied-run micro-order, tied-name resolution, sync chain order, and the bisect span order. All five now read hashes through the backing-aware door, which answers from the image's pool on the image path and from the store on the full path. The order is unchanged on both. ## Not hittable again The empty placeholder store is gone. An image-backed state now carries a trap store: any raw store read under image backing panics immediately, in every build mode, naming the door to use — on any input, not only on a tie. The query-equivalence fixture now seeds an exact-mtime tied pair (and fails if the tie is ever lost from the fixture), and the `.fast_read` equivalence test compares the entire timeline ordering across both backings. Reintroducing the defect turns that test red with the named panic. Also fixed while there: bare `zit info` ignored `--no-cache`; it honours it now. ## Compatibility - Artifacts, tags, and the sync protocol are unchanged; Fossil RFC revision 00 remains the target. - No on-disk format changed (the image schema stays at version 6). - No command, flag, or output changed, beyond `info --no-cache` now meaning what it says. ## Qualification `zig build test`, `e2e`, `smoke` (Fossil interop against a real `fossil`), `muscle` (41 differential steps), `git-import-e2e`, `git-export-e2e`, and `dst`, plus the three-runner CI battery (macOS ARM64, Linux x86-64, Linux ARM64). The fix was verified against the repository that first crashed: 0.3.3 exits with SIGSEGV on bare `zit info` there, 0.3.4 prints the checkout.