Timeline

mv recorded the rename durably before attempting the filesystem move and rolled nothing back when it failed, leaving the set naming a path that does not exist and commit ready to record a rename that never happened. The reversal mv --help promises -- "run zit mv NEW OLD" -- failed too: it saw the old path still occupied and refused the collision.

mvCommit now renames first, then records; if the record fails the file is renamed back and nothing is persisted. Move-first beats record-first because undoing a durable write needs a second durable write, which can itself fail, nesting a failure inside the failure handler. Renaming a file back cannot realistically fail -- the source directory and name are still free. Build the guarantee on the rollback that cannot fail.

mvCheckLegal gains a dest-parent-exists check: stat of a path under a missing directory fails, so the old collision check read "absent" and waved it through. Residual window: a crash between move and record leaves the file at NEW with the set naming OLD, recoverable with add NEW + rm OLD.

ENOENT and EACCES were both rendered "input/output error". check-in: d7dd9ea30b user: dmestas tags: blockers

`tag` was read-only: `tag list` was the only subcommand, so a repository could not be given a name for a check-in at all (blocker B6). The verb told the truth about what existed, but the capability was simply absent.

WHAT CHANGED

`zit tag add NAME CHECKIN` mints one CONTROL artifact carrying a single `T +sym-NAME` card targeting the resolved check-in's 64-hex hash.

THE SIGN IS THE WHOLE CORRECTNESS ARGUMENT. The card is a SINGLETON (`+`), not a propagating (`*`) tag. `repostate.resolveName` (src/repostate.zig:891) picks the max-`event.mtime` check-in among ALL active `sym-` rows, so a propagating `*sym-v1` would be inherited by every descendant and then resolve to the NEWEST of them — the name would silently drift off the check-in the user tagged, which is the same class of wrong answer as B1. `applyTagOps` (src/repostate.zig:727) gates propagation on `op.type != .singleton`, so a `+` card pins the name with ZERO repostate changes. The contrast with a branch is deliberate and now documented at both sites: a *branch* sym propagates precisely because descendants must inherit it; a *tag* sym does not, precisely because they must not.

`amend`'s steps 5-6 — assemble the control manifest, run the runtime-safety round-trip self-check, `putArtifact` + `commit` under the single fsync — are extracted into `mintControlArtifact`, and `tag add` is its second consumer. Both verbs resolve a check-in, compose a T run, then mint; that last step is now written once. amend's existing battery guards the extraction unchanged. The helper's error set is `logstore.OpenError`, the widest of the three the body can produce, so each verb renders it under its own name.

`tag add` closes its read view BEFORE the read-write append (commit's durability pattern), so it owns its repository lifetime rather than sharing the listing path's `defer repo.deinit`. Resolution and the empty-NAME check both precede the mint: a run that cannot resolve its CHECKIN mints nothing, asserted by a test.

`selectInheritedSyms`'s comment said zit mints no singleton syms itself, so the §6.2 exclusion of them from a branch move's cancel set was reachable only via a synced `T +sym-X *`. That is no longer true — the comment is corrected. The behavior needed no change, and its unit test already covered a singleton sym.

RECORDED, NOT ASSUMED: branch creation shares no read-only gap. It is already served by `commit --branch`, which mints the propagating branch/sym pair directly on the check-in manifest (src/cli.zig `composeCommitTags`), so there is no `branch add` to write. Cancel/remove semantics stay deferred to 0.2 — closing "cannot create tags" is the blocker; a full tag lifecycle is not.

RED PROOF (per BLOCKER-FIX-PLAN.md section 2, no product code changed until RED was proven; markers `// REGRESSION B6:`)

End-to-end, src/e2e.zig — all five failed pre-fix at `tag add` with exit 2 ("unknown subcommand 'add'"):

cli REGRESSION B6: tag add creates a tag that tag list and tag list CHECKIN report cli REGRESSION B6: a created tag pins to its check-in and is not inherited by a descendant (tag before commit) cli REGRESSION B6: a created tag pins to its check-in and is not inherited by a descendant (commit before tag) cli REGRESSION B6: a created tag survives pack cli REGRESSION B6: a created tag survives a clone

The pinning pair runs both orderings — tag-then-commit exercises inheritance at commit time, commit-then-tag exercises the propagation walk over already crosslinked descendants. Identical behavior in both is what proves the mechanism rather than luck. pack and clone prove the round trip: a synced artifact that does not survive sync is a worse lie than a missing verb.

Added alongside them: `tag add`'s arity errors, and an unresolvable CHECKIN leaving no tag behind. Unit, src/cli.zig: the parser's add grammar (both positionals required, `--help`/bad option winning over arity, `--` handling), `composeTagAddCards` minting exactly one `+sym-` card at the target, its control round trip through `artifact.parse` proving the sign survives the wire, and leak-freedom under `checkAllAllocationFailures`.

TEST EVIDENCE NOW

In this worktree at the committed tree: `zig fmt --check .`, `zig build`, `zig build test`, and `zig build e2e` each exit 0 — full battery, no filtering.

CHANGED EXPECTATIONS (both encoded the missing capability, nothing else)

cli tag B-tag-7 (src/cli.zig) and cli tag B-tag-13 (src/e2e.zig) used the literal token `add` as their stand-in for "not a subcommand". `add` IS one now, so both use `cancel`, a word that still is not.

cli tag B-tag-11's verbatim `tag_help_expected` gains the `add` usage line and its paragraph, because `tag --help` must teach the new grammar.

No borrowed technique: the singleton-sign argument and the mint extraction are original to this change. No performance claim is made.

SIBLING MERGE

This checkout absorbed the sibling B3 commit (1aeb531cac) before landing. The only conflict was in src/e2e.zig and was positional, not semantic: both changes append a new regression block at the end of the file. Both blocks are kept, one copy each; the two candidate B3 hunks fossil presented were byte-identical, and the full battery above was re-run on the merged tree, not just on mine. check-in: d8e5e8117d user: dmestas tags: blockers

A symlink anywhere in the checkout permanently wedged `commit`. `extras.zig` classifies a symlink as an extra (B-extras-9), and the recursive `add DIR` / `addremove` paths reuse that sweep as their add set without re-applying the kind test that explicit `zit add sym.txt` and `commit` both apply. The recursive path therefore TRACKED exactly what the direct path REFUSED: after `zit add .`, every subsequent `zit commit` died with "cannot commit 'sym.txt': not a regular file", `zit status` called an on-disk file missing, and the only way out (`zit rm sym.txt`) was named nowhere. `add .` is the documented whole-tree workflow, so any repo containing a symlink was stuck.

WHAT CHANGED

Consistent refusal: 0.1.0 does not version symlinks, on every path.

1. `extras.Extras` entries widen from a bare path to `Entry{path, is_symlink}`. The sweep already lstat-classified every entry (`resolveKind`); the verdict now rides out on the entry instead of being re-derived by callers. That is the point of the shape: `add` and `addremove` do NOT re-stat swept items, so the two paths cannot drift from the deep module's classification again — which is the mechanism of this bug. Ordering is unchanged (sort is by `path`; `is_symlink` never participates), and every postcondition assert is preserved.

2. The five `items()` consumers split by role. `extras` and `clean` ignore the tag — enumerating verbs do not judge, and a symlink stays a listable, deletable extra. `add`'s directory sweep and `addremove`'s insert loop filter on it.

3. `classifyPath`'s catch-all `else => .not_regular` splits: `.sym_link` gets its own `Outcome` and the wording `symlink (not versioned in 0.1.0)`; a fifo/socket/device keeps "not a regular file". Those are not the same refusal and must not read as one. The wording is one shared const so the explicit refusal and the recursive skip notice cannot diverge.

4. `commit`'s `Capture.not_regular` carries whether the entry was a symlink, and `commitNotRegular` renders the recovery for that case: "run 'zit rm PATH' to stop tracking it". This is how repos already wedged by a pre-fix `add .` get out; there is no migration code and none is needed.

REPORTING DECISION (stated, not implied)

`add` prints each skip to stderr, alongside its existing already-tracked notice: add's contract is per-argument feedback. `addremove` withholds symlinks SILENTLY. Its report is a two-channel ADDED/REMOVED ledger of state transitions, and a skipped symlink is a non-transition; growing a third notice channel there would change the shape of a report other tooling reads. `zit extras` is the verb that shows the symlink is still present and untracked.

`status` needed no change: post-fix the symlink is simply untracked.

TESTS

Five e2e regressions, marker `// REGRESSION B3:`: the breakdown doc's repro chain verbatim (init/add ./commit/status/extras); an `addremove` variant with symlinks sorting BOTH before and after the regular file the sweep also yields, so a filter that latched off the previous item's kind fails one of the two; explicit `add sym.txt` refusing with the symlink wording and tracking nothing; the wedge-recovery chain (pre-tracked symlink -> commit names `zit rm` -> rm -> commit succeeds -> status clean); and a `clean --dry-run` contract-partner guard that was green before the fix and stays green through it, proving clean still lists a symlink as an extra after the `Extras` type change. A unit assertion in `extras.zig` pins the tag itself, and `commitNotRegular`'s renderer test covers both branches.

Two pre-existing e2e expectations changed, both because they encoded the bug or its wording:

- `cli addremove B-addremove-2` asserted the ADDED set was byte-identical to `zit extras`, symlink included. That identity IS the defect. It now asserts the add set is the extras set MINUS symlinks, and additionally that the symlink remains an extra. - `cli add B-add-5` asserted the fifo-generic wording for a named symlink. It now asserts the symlink-specific wording.

Four `commit` invocations inside the new B3 tests use `runCommitEnv` with an explicit user rather than bare `runZit`; the isolated e2e environment has no resolvable author, which is a harness requirement, not a behavior change.

TEST EVIDENCE

In this worktree at the committed tree: `zig fmt --check .`, `zig build`, `zig build test`, `zig build e2e` (417 tests) and `zig build dst` each exit 0 — full battery, no filtering. Pre-fix the four B3 repro tests failed and the `clean --dry-run` guard passed, as designed.

No borrowed technique: the entry-tag shape is original to this change. No performance claim is made. check-in: 1aeb531cac user: dmestas tags: blockers

Three commits made inside the same second made `zit` return the WRONG file content for `tip` and `trunk`, and made the binary contradict itself: `zit info tip` reported "leaf: no" while `zit leaves` named the same check-in a leaf. `zit cat f.txt tip` returned the ROOT's content and `zit cat f.txt trunk` returned the MIDDLE's, on a three-commit chain whose newest content was `v3`. A version-control system that silently hands back an old revision under a name that means "newest" is disqualifying, so this lands before anything else.

WHAT WAS WRONG — three independent tie sites, not one

The originally-recorded diagnosis blamed a single lexicographic artifact-hash tiebreak in `mergeBaseOf`. That was wrong for the reported symptom: the RED-proof gate built the equal-mtime chain in BOTH hash orderings and observed IDENTICAL failures, which rules out hash order as the mechanism. Fixing only that line would have left `cat tip` and `cat trunk` still returning wrong answers. The real picture:

- `tipForm` — `mtime > best_mtime`, a strict `>` with no tiebreak at all, so the first entry in `events` INSERTION order won. Symptom: `tip` -> ROOT. - `resolveName` — ties settled by `tagxref` hash-map ITERATION order. Symptom: `trunk` -> MID. - `mergeBaseOf` — lexicographic artifact hash. A genuine defect, proven RED at unit level, but not the cause of the tip/trunk symptom and unreachable from the e2e merge path.

WHAT CHANGED

Equal-`event.mtime` ties are now settled by DAG ancestry: a descendant beats its ancestor. Genuinely concurrent nodes — same mtime, no ancestry relation — keep a deterministic least-artifact-hash fallback, documented at each site; hash order between UNRELATED leaves was never the bug. The shared helper (`MtimeMaxPick`) is used by `tipForm`, `resolveName`, `openLeafOf` and `dateResolve`, so every symbolic-name surface settles ties one way.

Timeline ordering gets a second pass that re-orders each equal-mtime RUN descendants-first, deliberately overriding the hash tiebreak. It is a per-run repeated-maximal-element extraction, NOT a sort predicate: "descends-from, else hash" is not a strict weak order, and handing it to `std.mem.sort` would be undefined behavior. Runs are bounded by the check-ins sharing one millisecond.

Settling a tie by ancestry allocates, so `resolveName`/`resolve`/`openLeafOf` gained `OutOfMemory`. Every caller switches it as an ABORT, never as a mismatch or "already correct" verdict — reporting an allocation failure as the exit-0 up-to-date message is exactly the lie those switches exist to prevent. `repository_test`'s closed-error-set assertion moved 2 -> 3 for that reason: it encoded the pre-fix set, not an inconvenient expectation.

Two ride-alongs on the same resolution surface:

- SF1 — `zit update trunk` used to fail as "invalid check-in ID": update accepted ONLY canonical 40/64-hex. Its argument is a check-in name like every other verb's, so it now runs the shared 8.3 procedure. A canonical ID still short-circuits, leaving update's cold path byte-for-byte as it was. - SF5 — a `tip` that names a non-leaf is now an in-binary assertion, not just a test. It is legitimate ONLY under a non-monotone clock (a child stamped strictly earlier than its parent); a child that TIES its parent means the ancestry tiebreak failed to fire, which is the defect itself. This tripwire would have caught the original bug.

RED PROOF (recorded by the RED-proof gate, 2026-07-19; per BLOCKER-FIX-PLAN.md section 2, no product code changed until RED was proven)

Unit, `src/repostate_test.zig`, deterministic equal-mtime chains built directly in BOTH hash orderings — no wall-clock dependence:

repostate REGRESSION B1: tip resolves to the descendant on an equal-mtime chain (head has the greatest hash) repostate REGRESSION B1: tip resolves to the descendant on an equal-mtime chain (head has the least hash) repostate REGRESSION B1: resolveName picks the descendant on an equal-mtime chain (head has the greatest hash) repostate REGRESSION B1: resolveName picks the descendant on an equal-mtime chain (head has the least hash) repostate REGRESSION B1: tip and resolveName agree with the leaf set in both hash orderings repostate REGRESSION B1: mergeBaseOf picks the deepest common ancestor when every candidate shares an mtime [failed pre-fix: expected 2, found 1]

End-to-end, `src/e2e.zig`, same-second commits with NO sleep between them — same-second IS the point:

cli REGRESSION B1: same-second commits resolve tip and trunk to the newest check-in cli REGRESSION B1 (SF1): update accepts a symbolic name and lands on the newest check-in cli REGRESSION B1: open materializes the newest same-second check-in into a fresh clone cli REGRESSION B1: a same-second two-branch merge picks the correct base and is never up to date

All of the above failed against pre-fix trunk; the two hash-ordering pairs failed IDENTICALLY, which is the evidence that retired the hash-order theory.

TEST EVIDENCE NOW

In this worktree at the committed tree: `zig fmt --check .`, `zig build`, and `zig build test` each exit 0 — full battery, no filtering. The only pre-existing expectation changed is the `repository_test` error-set count noted above, and it changed because it encoded the old set.

Markers `// REGRESSION B1:` are stable so state probes can grep trunk for them.

No borrowed technique: the ancestry tiebreak and the per-run topological micro-ordering are original to this change. check-in: bdb49cc5ca user: dmestas tags: blockers

Lands the last of the seven 0.1.0 release blockers. merge3 — the three-way merge — had no fuzz target, and silent merge corruption is the worst failure a version-control system can have, because it produces a tree that looks right.

The merged tree was re-verified on trunk after the merge, not inherited from the branch: zig fmt --check ., zig build, and zig build test all exit 0. The merge reported no conflicts and touched four files; fossil extras is empty, so nothing referenced went unadded. The conflict-marker sequences a repo-wide grep reports in src/merge3.zig and src/e2e.zig are that module's own sentinel constants and the tests asserting on them, not merge residue.

Landed by hand rather than by the release workflow: its TigerStyle gate spent its three-round budget on this diff and halted without a confirming pass. The final round's two blockers were real — a zig fmt failure and an oracle hole where conflict spans were validated individually but never as ordered and disjoint, which would have let one widened span exempt every line from oracle 4 — and both were fixed by the round that followed. Verified here before landing: fmt clean, the ordered/closes_once checks present, and merge3_properties running clean at seed 1 over 2000 rounds. check-in: 08e7c6d6f1 user: dmestas tags: trunk

Silent merge corruption is the worst failure a version-control system can have — it produces a tree that looks right — and merge3 had no fuzz target. This adds one, driving the merger with generated base/current/other triples and asserting the properties that must hold for any input.

Oracle 4 (no invented lines) needs a carve-out, because the merger is supposed to fabricate lines inside a conflict envelope. That carve-out is only sound if the recorded spans really are envelopes, so expectNoInventedLines validates the claim before subtracting anything: each span must be in-bounds, open at a line boundary with conflict_sentinel, close with conflict_terminator, start at or after the previous span's end, and carry no second terminator inside it.

The ordering and interior-terminator checks are load-bearing, not belt-and- braces. inAnySpan matches on overlap, so an over-long span exempts every output line up to its end. End-pinning alone admits a single span stretched from the first envelope's start to the last one's end — it opens and closes correctly and overlaps nothing — which would exempt the clean lines between two envelopes from the oracle entirely. closes_once catches that case on the first envelope's terminator. merge3 asserts ordering itself, but only under runtime_safety, which a ReleaseFast sweep — the build a fuzz run uses — erases; this loop holds in every optimize mode.

merge3.zig gains one export: conflict_terminator, the closing counterpart of the existing conflict_sentinel, with a comptime tripwire pinning its shape. Additive only, no behavior change — it lets the oracle pin both envelope ends against the module that produces them instead of re-typing the literal, so the two cannot drift apart.

Battery green in the worktree: zig fmt --check ., zig build, zig build test, zig build e2e, zig build dst (6 seeds x 1000 steps). The new target runs clean at seed 1 over 2000 rounds; no bug was found, so no regression seed is pinned. closed check-in: 21ca364fb3 user: dmestas tags: release-0.1

Two gaps the first green run exposed.

The repository carried 26 fuzz targets that CI never fuzzed. They reached CI only through their fixed-seed smoke tests inside `zig build test`, so the fuzzing investment was half-realized: the targets compiled and ran a handful of canned cases, but nothing swept them. `zig build fuzz` runs one target per invocation, so the new step loops. The target list is read from the step's own usage output rather than kept in the workflow — a target added to fuzz_tests.zig is swept automatically, with no second list to drift. Seed and rounds are fixed (1, 2000), not random: a red run has to be reproducible verbatim on a developer machine. Bare `zig build fuzz` exits non-zero because it is a usage error, so the enumeration tolerates that; every real invocation still fails the job. Verified by running the identical block under bash — 26/26 targets pass at seed 1.

src/ci_test.zig moves with it. `fuzz` leaves not_in_ci (its stated reason was that wiring a bounded CI invocation belonged to a later step — that step is this one) and a new ci_parameterized table records it as covered-in-a-loop, carrying the exact anchor that proves the invocation exists. The anchor is verified, not trusted: an entry whose anchor drifts out of the workflow fails like any other gap. That distinction is kept separate from not_in_ci on purpose — conflating 'runs, in a loop' with 'deliberately skipped' is how a step silently stops being covered while a stale excuse keeps the pin green.

actions/checkout v4 -> v5 clears the Node 20 deprecation warning the green run reported. check-in: 394b4efa27 user: dmestas tags: trunk

GitHub-hosted runners are unavailable to this repository: it is private, and private-repo Actions minutes are billed, so the first hosted run never started — 'recent account payments have failed or your spending limit needs to be increased', zero steps executed. The gate now runs on the self-hosted mac-mini-zit (macOS/ARM64), which is online and already carries the toolchain.

- runs-on names the specific machine ([self-hosted, mac-mini-zit]) rather than bare self-hosted, so a second runner joining the account cannot silently pick this job up on a different OS or architecture. - The Zig tarball is the aarch64-macos build with its published digest from ziglang.org/download/index.json. macOS ships shasum rather than GNU sha256sum, so the digest is compared explicitly; a swapped tarball still fails the job rather than building silently. - fossil is verified rather than apt-installed — the runner is a developer machine carrying 2.28, newer than what apt ships. The step hard-fails when fossil is absent, because a skipped smoke step would silently stop exercising the conformance claim the release rests on.

src/ci_test.zig moves in lockstep: the runs-on line, the digest constant, the digest-check form, and the fossil-guard pin all now assert the macOS shape. Pins and workflow must change together or zig build test goes red, which is the point of having them. check-in: c8cccb2723 user: dmestas tags: trunk

Lands P4-F6, closing the last unfuzzed attack surface in the release scope. transport.zig and serve.zig are the only two files a remote peer can reach with bytes it fully controls, and neither had a fuzz target: the sync_parsers_adversarial target covers the layer above them, so the HTTP framing itself — the first code to touch untrusted input — was exercised only by hand-written smoke cases. These two targets hit that framing directly.

The increment: src/transport_fuzz.zig (205 L) and src/serve_fuzz.zig (303 L), registered in the fuzz_tests.zig dispatch table alongside the existing 24 and pinned by that file's registration test. serve.zig's driveHttp is promoted to pub with a comment stating why — it is the receiveHead to handleHttpRequest seam the smoke tests and the fuzz target both need, and duplicating it would have meant fuzzing a copy of the request path rather than the real one. Both sides stay in-memory, so neither target binds a port and neither can flake in CI. dst.zig picks up the two targets plus fuzz_tests.zig itself, the latter so the registration pin has a test step to run in: zig build fuzz has none.

Evidence, re-verified on the merged tree rather than on the branch, since trunk had advanced: zig fmt --check ., zig build, and zig build test each exit 0. Both new targets run clean seeded — invoking zig build fuzz with each target name and --seed 1 exits 0 for transport_frame_garbage and for serve_request_garbage — and found no crash, leak, or UB to fix, so this step carries no pinned-seed regression. The merge reported no conflicts; a repo-wide grep for conflict markers is clean, and fossil extras is empty, so both added files are tracked and nothing referenced went unadded. check-in: b8db5ecabd user: dmestas tags: trunk

The 24 existing fuzz targets cover the delta, artifact, sync-parser and logstore layers, but not the two CLI-layer modules that consume bytes an untrusted remote peer chose. `sync_parsers_adversarial` covers the layer above; the HTTP framing itself was unfuzzed. These are the last two wire surfaces on the release bar, and they are what a hostile peer reaches first.

What landed:

- `src/transport_fuzz.zig` — `frameGarbage`, registered as `transport_frame_garbage`. Client-side §4/§4.1 framing and redirect policy: the round-trip law (whatever `frame` produces, `unframe` returns exactly those plaintext bytes), mutation of framed containers (bit damage never survives as *different* plaintext — it either fails the container's Adler-32/zlib checks or, in the length-field range the §4.1 compression-length erratum makes a capacity bound, decodes back to the same bytes), and garbage `Location` headers through `resolveRedirect`. Totality is the asserted contract: every input yields a value whose postconditions hold or a declared member of `TransportError`.

- `src/serve_fuzz.zig` — `requestGarbage`, registered as `serve_request_garbage`. Server-side HTTP request path: raw bytes into `std.http.Server.receiveHead`, then `handleHttpRequest`'s dispatch (`classifyXfer` -> body read -> responder -> reply framing). It does not re-feed `handleXfer` in isolation — that decoding is already fuzzed twice — it reaches it only as the tail of a full-path dispatch, which is the point. Asserted contract: any `receiveHead` error is a clean rejection, `handleHttpRequest` returns void, and any produced response begins with an HTTP/1.1 status line.

- `src/serve.zig`: `driveHttp` becomes `pub`. It is the request-path seam two callers need and neither should reimplement — the §4 smoke tests and this fuzz target. In-memory reader/writer on both sides, so the target binds no port and cannot flake in CI.

- `src/fuzz_tests.zig`: both targets registered in the `targets` table, and `targets` becomes `pub` for a new structural registration pin. An unregistered target compiles, passes review, and is then never run by any invocation; the pin asserts every target the release bar names is actually reachable from the runner, so the registration cannot rot.

- `src/dst.zig`: aggregates both new files plus `fuzz_tests.zig` into `zig build test`. This root is the one that reaches serve.zig and transport.zig relatively while carrying the `zit` dep those two import; `zig build fuzz` has no test step, so it is also the only place the registration pin can run.

No bug found, so no fix and no pinned-seed regression in this commit — both surfaces held over the seeded runs below. The targets are the standing check, not a one-time sweep.

Test evidence (this worktree, after `fossil update` absorbed the sibling `zit open` commit 5ba418801d and its 8 modified files):

- `zig build fuzz -- transport_frame_garbage --seed 1 --rounds 2000` — clean, no crash/leak/UB. - `zig build fuzz -- serve_request_garbage --seed 1 --rounds 2000` — clean, no crash/leak/UB. - `zig build test` — green, including the new registration pin and the fixed-seed smoke tests at the foot of both new files. - `zig build` and `zig fmt --check .` — green.

No borrowed technique in this change. check-in: cec4afaf89 user: dmestas tags: release-0.1

Lands the last of the three P3 CLI cliffs. A clone previously produced only an artifact log: there was no verb that turned one into a working tree, so clone-to-usable-checkout was unreachable and unproven by any test. `zit open` closes that path, resolving the trunk tip and materializing the check-in into the target directory.

The merged tree — not merely the branch — was re-verified on trunk after the merge: zig fmt --check ., zig build, and zig build test all exit 0. The merge reported no conflicts and touched six already-tracked files; fossil extras is empty, so nothing referenced went unadded. The conflict-marker byte sequences that a repo-wide grep reports in src/merge3.zig and src/e2e.zig are that module's own conflict sentinel and the tests asserting on it, not merge residue.

Landed separately from the sibling status increment (3b7fe2fbe1) rather than folded into one commit: the two are independent release steps and each keeps its own subject and evidence. check-in: 91c682fd06 user: dmestas tags: trunk

Lands release step P3-F5-status on trunk, completing the B-status-16 deferral.

The increment: `status` previously classified only `added` and `missing`, so a tracked file that was present but modified produced no line at all — the gap was documented in a comment, in `--help`, and in an e2e test that pinned the silence. Documenting a hole is not the same as not having one, and "your working copy looks clean" is the wrong thing for a version control system to say about an edited file. `status` now resolves the current check-in and compares every tracked file against it, emitting an `edited` row when the bytes or the file mode differ; a file whose contents match is still not listed.

The comparison is not a second implementation. The check-in resolution, the legacy trailing-separator F-card tolerance, the delta-manifest walk, and the merge against the sorted managed set were all machinery `diff` already had; that machinery is extracted into `CheckinBaseline` and `walkWorkingTree`, and both verbs now run through it, with each verb supplying only a sink. `diff` is a pure refactor here — same output, less code. Dirtiness remains a non-failure: every `added`/`edited`/ `missing` row exits 0 (B-status-15); only a genuine comparison failure exits 1. `--help` no longer defers edited-file detection and now narrows the deferral text to the two cases that genuinely remain out of scope.

This lands the full detection called for by P3-F5, not the fallback. The plan's fallback of record required an explicit operator decision; none was taken and none was needed.

Merge evidence: `fossil merge release-0.1` reported no conflicts, updating only src/e2e.zig and src/main.zig. The tree carries no conflict markers — the three open-marker occurrences a grep turns up in src/e2e.zig are string literals inside assertions pinning zit's own merge3 conflict sentinel, not merge residue.

Verification evidence: the merged tree — not merely the branch — was re-verified on trunk after the merge. `zig fmt --check .`, `zig build`, and `zig build test` each exit 0. Behavioral evidence rides in the branch commit's new e2e coverage, which pins each acceptance criterion: an edited tracked file is reported as edited; a rewrite with identical bytes (mtime bump, same content) is not reported; an executable-bit-only change is reported; a file deleted from the check-in but no longer tracked is still not reported; and a delta checkout with an absent B-card baseline fails cleanly rather than reporting a false clean tree. The e2e that pinned the old deferral is replaced by those tests, and the help-text e2es compare against a hand-written expected string, so the `--help` change is pinned too.

`fossil extras` is empty, so the merge adds no file it fails to track.

No performance claim is made here. No borrowed techniques in this change, so no attribution is owed. check-in: 3b7fe2fbe1 user: dmestas tags: trunk

`zit clone` builds a repository file and nothing else. The checkout it left behind was the same UNBORN record `init` writes (`version == ""`, branch `trunk`), with no managed set and no files, and there was no way to turn it into a usable tree: `zit update` accepts only a literal 40/64-hex check-in ID, so a freshly cloned tree could not name its own tip. Clone was a dead end.

`zit open` is the second half of fossil's own clone+open UX. It resolves the tip of the main branch out of this repository's derived state and hands materialization to the SAME `update.applyCheckin` engine every other working-tree move rides — journal-armed, transactional, rollback-safe. Tip resolution is the only work that is open's own; everything else is wiring.

What changed:

- `cli.parseOpenArgs` / `OpenArgs` / `OpenResult`: an operand-free surface. `-h`/`--help` is the only accepted token and wins over every other token; a bare `-x` is an unknown option, anything else an extra argument. The verb takes no operand by design — it derives its target from the repository. - `main.runOpen` plus the `open` entries in the `Verb` enum, the dispatch switch, and the `verb_help` table, so the verb is added in one place and the total switch stays total. `runOpen` writes NO checkout record and NO managed set of its own: `init` already wrote the unborn record, an absent managed set already reads as the empty set, and the update engine stays the single writer of the born record. A second writer of that bootstrap state would only be a second thing to keep in sync. - `main.openApplyFail`: one arm per `update.ApplyError` variant and no `else`, so a new variant fails the compile and forces a decision, mirroring `updateApplyFail`. `SymlinkUnsupported` / `InvalidPath` / `ReservedPath` are raised while planning the TARGET manifest and are reachable on a perfectly intact repository, so they get honest prose instead of a corruption claim. - `update.planUpdate`: an UNBORN record now takes the same arm as an absent one. Unborn is the normal state of every fresh repository, so without this the first `update` after a clone handed `""` to `buildPlan`, failed `artifact.validateName("")`, and reported `CurrentStateInvalid` — a clean, correct tree diagnosed as broken. A record that names no check-in but claims a merge parent or a pending special operation stays incoherent and is still `CurrentStateInvalid`. - BORN-ness, not presence, is the "already open" signal. A presence-based gate would have rejected a clone followed by an open on every clone, the primary path the verb exists to serve.

Test evidence (all run in this worktree after absorbing the sibling P3-F4 commit 281c0ed815, which arrived during this step and was merged by hand in `src/e2e.zig` — both sides had appended the identical P3-F4 block, so the duplicate was dropped):

- `zig build test` — green, including new `update_test.zig` coverage of the unborn-record arm and its incoherent-record rejections. - `zig build e2e` — green, including the P3-F3 block: clone → open → byte-identical tree → update → commit round-trip; a plain clone's unborn checkout tolerated by `update`; an untracked file in the way failing the open and materializing nothing; re-opening an already-open tree refused with no change; a repository with no check-in reported rather than failed; outside a repository failing with the not-a-repo diagnostic (exit 1); unknown option and positional as usage errors (exit 2); and the verb present in top-level help with one help text behind both `--help` and `help open`. - `zig build smoke` — green, with the new S6 scenario (§3.7/§4): `zit clone` + `zit open` against a REAL fossil server materializes the committed bytes byte-for-byte. This is the cross-implementation proof that the new path produces a working tree fossil itself agrees with. - `zig fmt --check .`, `zig build`, and `zig build dst` (6 seeds x 1000 steps) also green.

No borrowed technique in this change. No new file: the work lands entirely in existing modules. check-in: 5ba418801d user: dmestas tags: release-0.1

Completes the B-status-16 deferral. `status` previously classified only `added` and `missing`: a tracked file that was present but modified produced no line at all, and the gap was documented in a comment, in `--help`, and in an e2e test that pinned the silence. Documenting a hole is not the same as not having one, and "your working copy looks clean" is the wrong thing for a version control system to say about an edited file.

What changed:

- `status` now resolves the current check-in and compares every tracked file against it, emitting an `edited` row naming the path when the bytes or the file mode differ. A file whose contents match is still not listed.

- The comparison is not a second implementation. `diff` already resolved the current check-in, tolerated the legacy trailing-separator F-card, walked the delta manifest, and merged that effective file set against the sorted managed set. That machinery is extracted into `CheckinBaseline` (open/resolve) and `walkWorkingTree` (the merge), and both verbs now run through it. `diff` is a pure refactor here -- same output, less code. The `diff*Fail` diagnostic mappers become `compare*Fail` and take the verb as a parameter, the shape `checkoutFail` and `managedFail` already used.

- A verb supplies only a sink with `emit(entry)`. `DiffSink` renders diff records; `StatusSink` renders human rows and drops the deleted-from-check-in class, which `status` still defers because it iterates the managed set. The sink is comptime-generic rather than an erased pointer pair: both sinks are known at compile time, so the call stays direct and type-checked.

- The whole report is buffered and written once, as `diff` already did. A comparison failure part-way through the walk now leaves stdout empty rather than a header above a truncated report. Dirtiness is still never a failure: every `added`/`edited`/`missing` row exits 0 (B-status-15). Only a genuine comparison failure -- unreadable tracked file, corrupt or unresolvable check-in -- exits 1.

- `CheckinBaseline` is self-referential (the walk borrows the resolver, which borrows the log, which reads through the file storage), so it is initialized in place and must not be moved. The open/deinit contract used to rest purely on each call site placing its `defer` correctly; an `opened` flag now makes that invariant assertable, and both `deinit` and the failure path assert it.

- `walkWorkingTree` carries a termination guard against the exact bound (one step per managed path, one per effective file), plus a per-iteration progress assertion, because correctness of the merge rests on every switch arm advancing exactly one cursor. Debug-only, alongside the existing debug-only assertion that the managed set is sorted.

- `--help` no longer defers edited-file detection. It documents the three row classes and narrows the deferral text to the two cases that genuinely remain out of scope: a file deleted from the check-in but no longer tracked, and untracked "extra" files -- pointing at `zit diff` and `zit extras`.

Test evidence: new e2e coverage pins each acceptance criterion -- an edited tracked file is reported as edited in the born state; a rewrite with identical bytes (mtime bump, same content) is not reported; an executable-bit-only change is reported as edited; a file deleted from the check-in but untracked is still not reported; and a current delta checkout with an absent B-card baseline fails cleanly rather than reporting a false clean tree. The pre-existing e2e that pinned the deferral is replaced by the tests above. The help-text e2es compare against a hand-written expected string, so the `--help` change is pinned too. `zig build` and `zig build test` pass in this worktree after absorbing the sibling add/rm recursion commit (281c0ed815), and the commit is proved against a clean `fossil open` checkout running `zig build` then `zig build test`. check-in: 02d993f860 user: dmestas tags: release-0.1

Lands release step P3-F4-addrm on trunk. `zit add DIR` and `zit rm DIR` were hard errors directing the user to name individual files, which made `zit add .` and adding a source subtree dead ends. The increment makes both verbs recurse: `add DIR` expands over the already-shipped `extras.sweep` of the checkout root rather than introducing a second walker, so the exclusions, the no-follow symlink posture, and the tracked-set subtraction are the ones `addremove` and `clean` already use, with the sweep lazy and memoized so multiple directory arguments still perform one enumeration. `rm DIR` expands over the tracked keys via `ManagedSet.iterate` rather than over the disk, so an already-deleted directory remains forgettable. A single containment predicate, `pathUnderDir`, serves both verbs so the prefix-boundary case cannot diverge between them. Help text and exit-status wording now describe recursion instead of the removed directory error.

Merge evidence: `fossil merge release-0.1` reported no conflicts, updating only src/e2e.zig and src/main.zig; the tree carries no conflict markers (the open-marker occurrences that a grep turns up in src/merge3.zig and src/e2e.zig are that module's own conflict sentinel constant and the tests asserting on it, not merge residue). The merged tree — not merely the branch — was re-verified green on trunk after the merge: `zig fmt --check .`, `zig build`, and `zig build test` all exit 0. `fossil extras` is empty, so the merge adds no file it fails to track.

No borrowed techniques in this change, so no attribution is owed. check-in: fca1e073c2 user: dmestas tags: trunk

`zit add DIR` and `zit rm DIR` were hard errors that told the user to name individual files. That made the two most common invocations -- `zit add .` and adding a source subtree -- dead ends, and it was the last place where the CLI asked the user to do work the repository already knows how to do.

What changed:

- `add DIR` now expands to every untracked file beneath the directory. It reuses the ALREADY SHIPPED `extras.sweep` of the checkout root rather than introducing a second walker: the same walk, the same exclusions, the same no-follow symlink posture `addremove` and `clean` use. The sweep is lazy and memoized for the whole invocation, so `zit add a b c` over three directories still performs exactly one enumeration. Because the sweep already subtracts the tracked set and the depth-0 control names, neither can be re-inserted or re-reported by the directory path. - `rm DIR` expands over the TRACKED keys via `ManagedSet.iterate`, never over the disk, so a directory the user has already deleted is still forgettable. Keys are copied into the arena before the first removal, because `iterate()`'s slice and its backing bytes are invalidated by `remove` -- the same discipline `addremove` uses for its remove set. Ascending order is preserved and every expanded key still passes the per-key control-file guard (B-rm-7). - One containment predicate, `pathUnderDir`, serves both verbs, so the boundary case cannot diverge between them: `src2/c` is not under `src`, because containment requires the separator immediately after the directory's bytes. - No new diagnostic class. `zit rm .` with nothing tracked resolves to the existing not-tracked message rather than inventing an empty-expansion error; `zit add .` on a tree holding only control files adds nothing and succeeds. - The `add` and `rm` help text and exit-status wording now describe recursion instead of the removed directory error.

Test evidence: the B-add-5 and B-rm-5 contract tests were rewritten to pin the new behavior (a named symlink is still rejected; a directory now recurses; `.` at the root is never reported as outside the repository), and a new P3-F4 block of end-to-end tests covers nested trees, prefix-boundary siblings, multiple directory arguments sharing one sweep, --dry-run, --hard, and rm of a directory that no longer exists on disk. `zig build test` passes in this worktree after absorbing the sibling packaging commit (3645c03e2d), and the commit is proved against a clean `fossil open` checkout running `zig build` then `zig build test`. check-in: 281c0ed815 user: dmestas tags: release-0.1

The mirror is a derived view for running CI, never a source of truth — fossil is the repository, and every push is a replay of fossil history, which is why it pushes --mirror and nothing is ever committed git-side.

Why a script when 'fossil git export' already works: its configuration (mirror directory and autopush URL) is per-checkout state, machine-local and invisible to anyone else cloning this repo. The script documents the one supported way to run the export and fails with the exact 'fossil git export ... --autopush ...' fix line when a checkout has never been configured.

It also re-drives the push explicitly rather than relying on autopush. Autopush is best-effort: the first export of the CI commit hit a transient connection refusal to github.com, left the local mirror ahead of the remote, and 'fossil git status' still reported up-to-date — because that status describes the export, not the push. Re-driving makes the push's exit status the script's.

The mirror is PRIVATE and stays private; the script never touches visibility. check-in: ef4efe16b3 user: dmestas tags: trunk

CI is the multiplier for the rest of the 0.1.0 sequence: from here every fix lands with fmt/build/test/e2e/dst/smoke gated automatically, and the smoke conformance claim — zit artifacts and deltas validated against the real fossil binary — becomes continuously enforced instead of milestone-manual.

- .github/workflows/ci.yml: single ubuntu-latest gating job on push and PR. Zig 0.16.0 pinned by version AND sha256 digest, verified with sha256sum --check --strict before use; fossil installed for smoke; the battery runs in order with a 20-minute job ceiling and a 5-minute bound on smoke, which is the one step that can hang without producing output. - src/ci_test.zig: structural pins over the workflow, so the file cannot drift from what it claims. Each pin is anchored to a whole line with its YAML indentation — a loose substring is satisfied by the phrase appearing in a comment while the block that governs the run says something else. The digest pin names ZIG_SHASUM and the tarball together, so the digest this repo pins is provably the digest the workflow checks. - src/packaging_test.zig: a negative-space pin asserting every path build.zig embeds is version-controlled. This diff is why: build.zig came to depend on .github/workflows/ci.yml while that file was untracked, and bare 'fossil extras' does not list dotfiles, so the commit-discipline check reported clean. The pin runs 'fossil ls' and fails on any embed that is not tracked.

The mirror is PRIVATE (github.com/danmestas/zit) and stays private; publishing is a separate decision that is deliberately not part of this release. check-in: 8a003b2ada user: dmestas tags: trunk

Second increment of the 0.1.0 release sequence, landed on trunk as it completes rather than accumulating to a big-bang merge at the end.

The increment: build.zig.zon .paths named the whole docs directory. A Zig package is cut from the working tree, not from what fossil tracks, so the ignore-glob does not govern it -- a bare docs entry ships whatever sits under docs/ at package time, including the ignore-glob'd docs/plans/*.md working documents, which are internal and must never leave the repository. .paths now names docs/rfcs directly, which is also what the repo convention already states (0ad7fa92c6: "docs/ is for the RFCs only"); the manifest encodes that convention instead of relying on docs/ happening to stay clean.

Evidence: a new pin in src/packaging_test.zig asserts both halves -- that .paths contains "docs/rfcs", and, as negative space, that a bare "docs" entry is absent, so the ship-everything form cannot drift back unnoticed.

The merged tree was re-verified before this commit: zig fmt --check, zig build, and zig build test all green on the merge result. Green on the branch does not imply green on the merge, since trunk advances with concurrent work.

No borrowed techniques in this change, so no attribution is owed. check-in: 0c22d3a950 user: dmestas tags: trunk

`.paths` named the whole `docs` directory. A Zig package is cut from the working tree, not from what fossil tracks, so the ignore-glob does not govern it: a bare `docs` entry ships whatever sits under docs/ at package time — including the ignore-glob'd docs/plans/*.md working documents, which are internal and must never leave the repository.

Naming docs/rfcs directly is also what the repo convention already states (0ad7fa92c6: 'docs/ is for the RFCs only'); the manifest now encodes that convention instead of relying on docs/ happening to stay clean. A new pin in src/packaging_test.zig asserts it so the bare-docs form cannot drift back. check-in: 3645c03e2d user: dmestas tags: release-0.1

P1 landed on trunk (8117eab3b2) per the continuous-integration rule, so the release branch absorbs trunk to keep a single lineage. Content-identical merge — this records the ancestry so later increments do not re-traverse it. check-in: 6d229acebf user: dmestas tags: release-0.1

First increment of the 0.1.0 release sequence, landed on trunk immediately per the plan's continuous-integration rule rather than accumulating to a big-bang merge at P6.

- LICENSE at the repo root (BSD-2-Clause, copyright Daniel Mestas 2026). zit is an independent reimplementation from the Fossil RFCs, not a derivation of Fossil source, so the choice was open; BSD-2-Clause matches the Fossil heritage and the systems-Zig ecosystem. - build.zig.zon .paths names LICENSE, so it ships inside a fetched package. - The commit-description-* scratch file is gone and the pattern is in the versioned ignore-glob. - src/packaging_test.zig pins these as executable facts, including a negative-space pin asserting every repo-root path build.zig embeds is also named in .paths — the embeds attach to the test-only module, never to the exported zit module, so a consumer never depends on a file outside .paths.

The merged tree was re-verified before this commit (fmt/build/test green): green on the branch does not imply green on the merge, since trunk advances with concurrent work. check-in: 8117eab3b2 user: dmestas tags: trunk

The release plan is a working document, not a shipped artifact. Repo convention (0ad7fa92c6) is that docs/ carries the RFCs only, with docs/plans/* already in the versioned ignore-glob; the plan, the readiness assessment, and its earlier draft all belong there. P1 added the plan because its own scope text said to commit it — that instruction is wrong and has been removed from the plan.

The file is unchanged on disk, now at docs/plans/RELEASE-0.1.0-PLAN.md. It remains in the history of 122998a428 — fossil history is immutable and shunning it would be disproportionate for a working doc. check-in: 3179b6805a user: dmestas tags: release-0.1

A release without a license grants nobody any rights, so this is the legally gating step of the 0.1.0 sequence. zit is an independent reimplementation from the Fossil RFCs rather than a derivation of Fossil source, so the choice was open; BSD-2-Clause matches the Fossil heritage and the systems-Zig ecosystem.

What changed:

- LICENSE at the repo root, BSD 2-Clause, copyright Daniel Mestas 2026. - build.zig.zon .paths now names LICENSE, so the file actually ships inside a fetched package instead of only existing in the checkout. - The leftover commit-description-413190fb92be991f.txt scratch file is gone and .fossil-settings/ignore-glob carries commit-description-* so the class of file cannot drift back in. - src/packaging_test.zig pins the above as executable facts: LICENSE content, LICENSE named inside the manifest's brace-matched .paths block, a line-anchored ignore-glob pin, and a negative-space pin asserting every repo-root path build.zig embeds is also named in .paths. These acceptance criteria are file-structure facts, which rot silently because nothing executes them; the battery alone cannot catch a .paths regression. - build.zig grows build_unit_test_module: the pinned repository files attach as anonymous imports to a test-only compile of root.zig, never to the exported zit module. Attaching them to zit made every consumer's build depend on files outside .paths and a fetched package failed on a missing .fossil-settings/ignore-glob before compiling a line. The negative-space pin exists to catch exactly that recurrence. - docs/RELEASE-0.1.0-PLAN.md, the plan of record for the 0.1.0 release, is committed alongside the first step it describes.

Test evidence: zig build and zig build test green in the working checkout. This commit is additionally gated on a clean-checkout proof — fossil open into a fresh temp directory, then zig build and zig build test there — which is the check that catches a file referenced but never added.

No borrowed techniques in this change, so no attribution is owed. check-in: 122998a428 user: dmestas tags: release-0.1

These four bench-run outputs (baseline / step2-pickbase / step3-pack-redeltify / step4-samepath) were measurement artifacts committed under docs/plans/bench — they do not belong in version control (docs/ is for the RFCs only). Remove them from the tip and add docs/plans/* to the versioned ignore-glob so the pattern cannot recur. They remain in the historical check-ins that added them (9aaf485847 and the integration merges) — Fossil history is immutable; purging them from provenance entirely would require fossil shun, deliberately not done. check-in: 0ad7fa92c6 user: dmestas tags: trunk

Lands amend, artifact, bisect, log PATH, annotate, merge --cherrypick/--backout, and addremove — the VCS-verb-survey recommendations — onto trunk, already integrated with the storage branch's pack re-deltification.

- amend: mint display-metadata T cards, never rewrite history (also corrects the git-reflex table's wrong immutability lesson). - artifact: the plumbing window (whatis + raw dump) over the one parser. - bisect: DAG binary search (bad/good/next/status/reset), state in .zit-bisect. - log PATH: per-file history folded into log (fossil finfo). - annotate: per-line provenance; the version chain is ordered by TOPOLOGY (matching fossil's generation walk), not mtime, so a parent is never misattributed to its child on a timestamp collision. - merge --cherrypick/--backout: alternate-baseline special merges recording a 4.7.14 Q card, rendered by info; the plain merge surface is byte-identical. - addremove: one sweep, add every extra and drop every missing.

Built decomposed (focused implementers + adversarial review) after the monolithic workflow thrashed on API instability. 1678 unit + 376 e2e + dst 6x1000 green. check-in: e5fffafdb8 user: dmestas tags: trunk

Brings trunk bab930 (the storage branch's at-rest re-deltification / zit pack generational rewrite, plus src/pack.zig and its bench baselines) into the cli-verbs-2 slice. One conflict, in src/root.zig — both branches added a module export at the same spot; resolved by keeping both (pub const bisect and pub const pack). logstore.zig and main.zig auto-merged. Integrated tree green: 1678 unit + 376 e2e; the seven new verbs and the pack pass together. closed check-in: e640119891 user: dmestas tags: cli

zit info on a cherrypick or backout check-in now shows a provenance line derived from the parsed 4.7.14 Q card: a 'cherrypick:' line for Q plus and a 'backout:' line for Q minus, each carrying the full REV hash, placed right after the parent and merge lines with the value column aligned. It reads through the shipped artifact parse path (repo.manifest then artifact.parse then parseQCard, iterating manifest.q) — no bespoke re-parse. A check-in with no Q card prints no such line and is byte-identical to before.

Also fixes an allocator-symmetry bug uncovered here: renderInfo now threads gpa (was arena) so info's manifest frees against the same allocator, ending an Invalid free panic at repo.deinit on every info call. Closes the last deferred clause of the cli-verbs-2 slice. 1678 unit + 376 e2e green. check-in: 4b1be918ab user: dmestas tags: cli

An adversarial review found zit annotate could charge a line to the too-recent CHILD when a parent and child check-in share an identical (or non-monotone) event mtime — the chain was ordered (mtime asc, hash). Fossil orders its annotate walk by pure topology (generation number, descendants.c/diff.c), so a parent is ALWAYS processed before its child. Match that.

New repostate.ancestryLinearized runs Kahn's over the reversed (child->parent) ancestry edges within the file's ancestor set, emitting newest->oldest with a (mtime desc, hash) ready-queue among topologically-INCOMPARABLE nodes, then reverses to the engine's oldest-first order — topology is now the PRIMARY key, mtime/hash only orders incomparable versions. annotateFile consumes it in place of the old sort; the attribute engine (primary-parent pass-through, oldest origin, binary refusal, layout) is unchanged. Amends the RESOLVED annotate-attribution rule. Linear/monotone history is byte-identical (degenerates to mtime-ascending); new tests (same-mtime parent-first, non-monotone, merge primary-parent) fail against the old order. 1678 unit + 376 e2e green. check-in: ff9662dfee user: dmestas tags: cli

fossil-style best-of-N delta base selection (pickBase, plan §5) plus a `zit pack` re-deltification pass with a monotonic-shrink guard (§6.1) and same-path candidates (§6.2). At-rest only: all four RFCs conformant, wire interop preserved, every repacked frame hash-verified against the log.

Measured (whole-file, index-inclusive): sqlite: 207.3 MB -> 174.4 MB (1.40x -> 1.18x vs fossil 147.7 MB) fossil-scm: 117.5 MB -> 108.1 MB (1.63x -> 1.50x vs fossil 72.2 MB)

The monotonic-shrink guard (keep the smaller of {existing frame, re-encoding}) is what turned re-deltifying a clone of fossil-quality wire deltas into a net win instead of a +33% regression. check-in: bab9303056 user: dmestas tags: trunk

zit addremove [--dry-run] — checkout-layer convenience (fossil/hg parity; git add -A). ONE scan via the shipped extras.sweep (the exact untracked/exclusion walk zit extras and zit clean use) is the ADD set; every managed file absent from disk (no-follow stat, as status checks) is the REMOVE set. Both mutate the managed set through the shipped ManagedSet.insert/remove/write (write-temp + fsync + rename) — no second walker, no ad-hoc mutation. A present-but-modified file is never touched; control/never-tracked names are never added. --dry-run leaves .zit-managed byte-identical and prints the same report (ADDED block then REMOVED block, each ascending, root-relative). 1675 unit + 374 e2e green. check-in: f0dc5f4e2a user: dmestas tags: cli

Both are alternate-baseline choices inside the shipped merge machinery, per merge-flags contract B-merge-30..40 (which lifts merge.md's v1 non-goal); the flagless zit merge NAME surface is byte-identical (B-merge-31 re-asserts it).

- --cherrypick REV: three-way with base = REV's primary parent, other = REV, current = checkout (apply REV's own changes). --backout REV: base = REV, other = REV's primary parent (reverse REV). Same classifyFile/applyMerge engine; a root REV yields an empty side; zero entries refuse (B-merge-39). Flags are mutually exclusive and reject an extra positional / dirty tree. - A cherrypick/backout commit stays SINGLE-parent (REV is never a merge parent) and mints exactly one artifact 4.7.14 Q card (Q +rev / Q -rev), cleared one-shot; a plain merge keeps its two-token P card and empty Q. - The pending op is a new checkout special_op field (4th TLV, no default, threaded everywhere); undo serializes it (journal fmt v1->2) so undo unwinds a pending cherrypick/backout (B-merge-35).

B-merge-1..29 e2e all still pass. 1675 unit + 362 e2e green; fmt clean. Follow-up: B-merge-41 (zit info Q-card render line) deferred — its pinned text was absent from the plan; the Q card is already readable via zit artifact. check-in: 20bf0a31c6 user: dmestas tags: cli

zit annotate PATH — which check-in introduced each line of one tracked file at the current checkout, and when. One canonical spelling (no blame/praise). The engine walks the file's full-ancestry version chain (repostate.ancestorsOf, the same 3.3 walk merge-base/bisect use; per-version content via Repository.fileAt, the one 8 effective-set query), diffs adjacent versions with the one house line-diff core (merge3.matchLines), and pushes each line's origin back to the OLDEST version carrying it. Across a merge, a line in ANY parent side is charged to that parent (primary first, repo-state 3.2), never to the merge; the merge is charged only for lines in no parent version. Output: 10-char hash, ISO date from event mtime, the line verbatim; a binary file refuses exit 1. Reviewed adversarially (merge attribution hand-traced correct). 1673 unit + 352 e2e green. check-in: f774a1a2a7 user: dmestas tags: cli

The bisect check-in landed every edited file but not the new bisect.zig itself (committed without a prior add), so that check-in would not build from a clean checkout. Add the file; no code change. check-in: b937bca55b user: dmestas tags: cli

Same-path predecessors sourced from check-in manifest walk, offered ahead of chronological window candidates (fossil's mlink analog per §6.2).

fossil-scm-clone: zit=108143984B fossil=72245248B ratio=1.4969 [Step-4 packed store (measured this run), accounting EXACT (header64 + zlib + delta + config == 108,143,984): zlib 8369 frames / 82,268,624 B (76.1%, avg 9830 B); delta 59130 frames / 25,875,208 B (23.9%, avg 437 B); config 1 frame / 88 B; raw 0. Artifact-type split: checkin/manifest 20848 / 23,816,728 B (22.0%), other-artifact 6929 / 4,706,432 B (4.4%), file-blob 39722 / 79,620,672 B (73.6%). Header+padding overhead 3,710,123 B (3.4%).] | sqlite: zit=174352688B fossil=147709952B ratio=1.1804 [Step-4 packed store (measured this run), accounting EXACT (header64 + zlib + delta + config == 174,352,688): zlib 9248 frames / 113,074,896 B (64.9%, avg 12226 B); delta 121746 frames / 61,277,640 B (35.1%, avg 503 B); config 1 frame / 88 B; raw 0. Artifact-type split: checkin/manifest 36515 / 65,427,440 B (37.5%), other-artifact 4775 / 5,462,856 B (3.1%), file-blob 89704 / 103,462,240 B (59.3%). Header+padding overhead 7,211,093 B (4.1%).] vs baseline: fossil-scm-clone: zit=117528088B fossil=72245248B ratio=1.627 [raw=0B/0f; zlib=92073728B/9647f (78.3%); delta=25454120B/57852f (21.7%); config=176B/2f. Header+padding overhead 3711845B (3.2%). Artifact-type: checkin/manifest 26721968B/20848, other 4835264B/6929, file-blob 85970616B/39722. Accounting exact.] | sqlite: zit=207344544B fossil=147709952B ratio=1.404 [raw=0B/0f; zlib=140422768B/10847f (67.7%); delta=66921536B/120147f (32.3%); config=176B/2f. Header+padding overhead 7212808B (3.5%). Artifact-type: checkin/manifest 81006048B/36515, other 5531960B/4775, file-blob 120806296B/89704. Accounting exact.] check-in: 0375766879 user: dmestas tags: storage

zit log CHECKIN [PATH]. With no PATH, behavior is byte-identical to today. With PATH, the ancestry walk emits only the check-ins that CHANGE that path: a check-in K changes PATH iff PATH's effective content (via Repository.fileAt, the one artifact 8 effective-set query — no CLI-side F-card re-derivation) differs from PATH's content in K's PRIMARY parent (first-listed P card, repo-state 3.2). Presence flips count (root add, delete, rename departure/arrival as delete+add, no old-name following); equal hashes are no change; a phantom parent reads as absent. walkLog gained an optional filter; the null path preserves the shipped DFS verbatim. The finfo/log split was historical accident, not design — one deep log replaces a shallow sibling, no new verb. 1661 unit + 343 e2e green; fmt clean. check-in: 6a360f33ff user: dmestas tags: cli

zit bisect bad NAME | good NAME | next | status | reset. Marking bad/good moves the checkout to the next probe automatically (fossil parity); next re-announces it; reset restores. The candidate set (full-ancestry ancestors of bad minus the good ancestor-sets minus skipped), the lower-median probe by ascending event-mtime with hash tiebreak, and the culprit are ONE general-purpose repostate query RepoState.bisectSpan, composed from collectAncestors / mergeBaseOf / isAncestorOf / mtimeOf / hashOf per the RESOLVED bisect-midpoint rule (repo-state 2/3.2/3.3/8.3) — the CLI never walks ancestry. Bisection state is checkout-local in .zit-bisect on the undo.zig state-file tier (atomic write + fsync, magic/CRC frame, corrupt -> exit 1), in the never-tracked/extras set; probe/culprit/reset moves go through the journal-armed update.applyCheckin behind requireCleanTree. Refusals (inverted marks, unrelated histories) exit 1. 1661 unit + 339 e2e green; fmt clean. check-in: 343d41b2f3 user: dmestas tags: cli

zit artifact HASH [--raw] — zit's cat-file/whatis. No flag: a whatis summary (hash, structural type per artifact 5.1/5.3, size, one line per A..W card in stored order, and the 6.2 Z self-checksum verdict). A blob reports type file, size, and binary-or-not. --raw emits the verbatim stored bytes. Resolves a 4-64 hex prefix over the LogStore (ambiguous -> exit 1), reads via the existing 7.2 blob path. Everything shown comes from the ONE existing artifact parser — refactored into frameNoZ/frame/assemble with a Z-tolerant parseWindow — never a CLI-side re-parse. 1649 unit + 335 e2e (13 new B-artifact) green; fmt clean. check-in: f477c3bf19 user: dmestas tags: cli

zit amend NAME [--comment TEXT] [--user NAME] [--date ISO] [--branch NAME] mints ONE control artifact whose T cards change how the target check-in displays — comment, user, date, and the repo-state 6.2 branch-move set — retargeted at the check-in hash, never '*'. History stays append-only: the original manifest is untouched and a new control artifact is crosslinked in (artifact 4.7.16 T / 4.7.5 D / 4.7.17 U / 4.7.19 Z; repo-state 4/5 crosslink, 5 tag propagation). Display is honored through a new general RepoState.activeTagValue / Repository.override consumed by timeline and info.

Also removes amend from the git-reflex rejection table: teaching against fossil-semantics amend with the immutability lesson conflated it with git's history-rewriting amend — amend is in fact the proof of zit's immutability, not a violation. 1643 unit + 322 e2e (15 new B-amend) green; fmt clean. check-in: 6c6d1babc2 user: dmestas tags: cli

The prior cli leaf was a closed integration point from before the recent slice; this reopens cli development at current trunk (timeline, mv, undo/redo, extras, clean, merge all present). The next verb slice — bisect, annotate, amend, artifact, addremove per the VCS verb survey — builds here and converges on cli, then one merge cli -> trunk. check-in: 9b5605ad79 user: dmestas tags: cli

fossil-scm-clone: zit=110083984B fossil=72245248B ratio=1.5238 (packed store, exact accounting header64+zlib+delta+config==110083984: zlib 8377 frames / 84,763,872 B 77.0% avg 10118 B; delta 59122 frames / 25,319,960 B 23.0% avg 428 B; config 1 frame / 88 B; raw 0. Artifact-type: checkin/manifest 20848 / 23,816,728 B 21.6%, other 6929 / 4,706,432 B 4.3%, file-blob 39722 / 81,560,672 B 74.1%. As-cloned baseline was 117,528,088 B zlib 9647/92,073,728; delta 57852/25,454,120; ratio 1.6268.)

sqlite: zit=175246544B fossil=147709952B ratio=1.1864 (packed store, exact accounting header64+zlib+delta+config==175246544: zlib 9260 frames / 113,048,584 B 64.5% avg 12208 B; delta 121734 frames / 62,197,808 B 35.5% avg 510 B; config 1 frame / 88 B; raw 0. Artifact-type: checkin/manifest 36515 / 65,427,440 B 37.3%, other 4775 / 5,462,856 B 3.1%, file-blob 89704 / 104,356,096 B 59.5%. As-cloned baseline was 207,344,544 B zlib 10847/140,422,768; delta 120147/66,921,536; ratio 1.4037.)

vs baseline:

fossil-scm-clone: zit=117528088B fossil=72245248B ratio=1.627 (raw=0B/0f; zlib=92073728B/9647f 78.3%; delta=25454120B/57852f 21.7%; config=176B/2f. Header+padding overhead 3711845B 3.2%. Artifact-type: checkin/manifest 26721968B/20848, other 4835264B/6929, file-blob 85970616B/39722. Accounting exact.)

sqlite: zit=207344544B fossil=147709952B ratio=1.404 (raw=0B/0f; zlib=140422768B/10847f 67.7%; delta=66921536B/120147f 32.3%; config=176B/2f. Header+padding overhead 7212808B 3.5%. Artifact-type: checkin/manifest 81006048B/36515, other 5531960B/4775, file-blob 120806296B/89704. Accounting exact.) check-in: efaf2d3ae1 user: dmestas tags: storage

Completes the checkout-and-history CLI slice — merge is the sixth and final verb (after timeline, mv, undo/redo, extras, clean). Line-based three-way merge into the working tree with fossil-style conflict markers, a mtime-independent up-to-date/ancestry gate, and a commit that mints the primary-first two-token P card and refuses while any marker remains. 1629 unit + 307 e2e green; dst 6x1000. check-in: c2c837c5e1 user: dmestas tags: trunk

zit merge NAME computes a three-way merge of NAME (other) into the current checkout and records the merge parent; commit then mints the two-token P card. Built from the RFC oracle + the RESOLVED merge-base and conflict-model rules.

- merge3.zig: a pure diff3 line engine + per-path classifier (no I/O, injected allocator, error{OutOfMemory}). Both-modified binary, add-vs-add, and modify-vs-delete are whole-file conflicts by construction, never laundered through the line merger (artifact §8.2; B-merge-21). Seeded-deterministic fuzz. - repostate.mergeBaseOf: the merge base over full ancestry (§3.3, merge parents included) — greatest event.mtime, ties by least artifact hash (§2/§8.3, the RESOLVED merge-base rule). repostate.isAncestorOf: a pure, mtime-independent full-ancestry membership test — the authoritative up-to-date gate, so a same-mtime ancestor can never slip the refusal. - merge verb: resolve NAME (§8, one resolver), refuse (exit 1, nothing mutated) a dirty tree / a pending merge / an up-to-date or unrelated NAME; else classify each §8.2 merge-walk path and materialize transactionally via update.applyMerge (journal + checkout written before the first byte moves). Conflicts write fossil-style markers, name each path on stderr, exit 1, and still record the pending merge; zit undo unwinds it (B-merge-13). - commit: with a merge pending, scan the committed set for the conflict sentinel and refuse until resolved (no override); otherwise emit the primary-first two-token P card and clear the merge one-shot (§4.7.13; B-merge-8/9).

v1 non-goals held: no rename-aware, binary-content, cherrypick, or octopus merge. 1629 unit + 307 e2e green; dst 6x1000; fossil interop unaffected. closed check-in: 6bdb918f18 user: dmestas tags: merge-verb

Two untracked-file management verbs over one shared control-name/sweep module (artifact §8 never-tracked superset; the .zit control files and derived sidecars are the exclusion set):

- extras: list files present in the working tree but not in the managed set and not control/derived files — the untracked surface, one path per line. - clean: remove those extras from the working tree, refusing to touch any tracked or control file; the sweep propagates allocation failure without leaking and never crashes on a hostile tree (fuzzed).

Slice tail: merge remains unshipped (its plan/implement agent repeatedly lost its API connection mid-response this session). Full unit + e2e (290/290) green on the merged trunk. check-in: bbfa0715f0 user: dmestas tags: trunk

Three checkout-and-history CLI verbs, each built to its B-verb contract and RFC oracle, each gated green (unit + e2e) before commit:

- timeline: list every check-in newest-first by event.mtime with an ascending full-hash tiebreak (repo-state §2, §8.3 item 7), merge check-ins marked M (§3.2), each on its branch with the configured main-branch fallback (§6.1/§6.4). - mv OLD NEW: rename a tracked file, moving it on disk and swapping the managed entry atomically; refuses (exit 1) an untracked OLD, an existing/tracked NEW, or a self-move; the rename records a one-shot NEW three-token on the next commit. - undo / redo: journal each sheltered mutation's pre-image (fsynced before the mutation) so update/revert are reversible; a corrupt or empty journal is a clean exit 1 with no partial restore.

Slice partial: extras, clean, and merge were not completed this run. Full unit + e2e green on the merged trunk. check-in: 89ef496c3b user: dmestas tags: trunk