Artifact d3aecf12565618a6b678eeff534230c88dbe5a02486beafcdbdf1eac9b258292:
- File
src/smoke.zig
-
2026-07-18 23:11:56
— part of check-in
[5ba418801d]
on branch release-0.1
— Add zit open: clone→working-tree path, proven by e2e chain and fossil smoke scenario
`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. (user: dmestas, size: 35907) [annotate] [blame] [check-ins using]
-
2026-07-18 23:19:04
— part of check-in
[91c682fd06]
on branch trunk
— Merge release-0.1: zit open — the clone-to-working-tree path (P3-F3)
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. (user: dmestas, size: 35907) [annotate] [blame] [check-ins using]
-
2026-07-18 23:11:56
— part of check-in
[5ba418801d]
on branch release-0.1
— Add zit open: clone→working-tree path, proven by e2e chain and fossil smoke scenario