Decode git's worktree enumeration, with the checkout as a coproduct so bare-with-a-head cannot be written

[gunbai-bot]

The typed reading of git.Core.WorktreeListIn's wire (landed in #9431), alongside the ref-set decoder in #9465.

The design choice worth arguing

GitWorktreeCheckout is a coproduct, not a record of optionals.

git reports a bare worktree with no HEAD line at all, and every non-bare worktree with a HEAD plus exactly one of branch or detached. A record carrying head? / branch? / bare would make four impossible states writable — bare-with-a-head, non-bare-with-no-head, both-branch-and-detached, and neither — each of which every consumer would then have to re-validate:

GitWorktreeOnBranch { head, branch } | GitWorktreeDetachedAt { head } | GitWorktreeBare

Carrying the head inside the arms that have one makes those states unrepresentable rather than checked (DESIGN §4b construction rung). One finalizer chooses the checkout, and refuses each impossible combination once with a located reason, instead of every downstream consumer re-deriving it.

An unmodeled attribute refuses rather than being skipped

git adds worktree attributes over time. Silently ignoring one we don't model would let a future flag change a worktree's meaning while this decoder kept reporting the old reading — a failure arm that widens instead of refusing (§5). locked and prunable are admitted bare or with a trailing reason; that reason is git's prose for a human, carries no decidable fact, and is deliberately not retained, since keeping it would invent a second authority for a string git may reword at any release.

Framing follows the transport

NUL-separated attributes, an empty record terminating each entry, exactly one trailing empty dropped. Two refusals that a laxer decoder would silently absorb:

• An unterminated final entry refuses. Dropping it would report fewer worktrees than the repository has.
• One malformed entry refuses the whole observation. A partial set is indistinguishable from a repository with fewer worktrees, so a consumer diffing two enumerations would read the drop as a removal and act on it.

The located grain is the entry, not the record, because an entry spans several records — the_refusal_locates_the_offending_entry pins that.

Accumulation is cons + one reverse at each exit rather than tail-append in the step (§6 bare-minimum-cost, same finding as review 56767 on #9465), and entries_preserve_the_emitted_order pins the order that no count-based witness can see.

Executed evidence

16/16 witnesses pass; the footer confirms all 16 ran.

The authored wire strings are transcribed from real git worktree list --porcelain -z output observed on a constructed repository — primary on a branch, linked on a branch, detached, locked, and a bare clone. I verified the test's entry() helper reproduces those real bytes byte-identically to a reconstruction from the observed entries, so the framing under test is git's rather than my assumption of it.

What this does NOT establish

Stated explicitly because reporting it as coverage would be rung inflation: that WorktreeListIn emits these bytes for any given repository state. That is a transport claim, it cannot execute inside the hermetic fold (a shell operation is refused at shell.Test.IsExecutable before the subprocess is reached), and mocking it would fabricate the very observation the claim is about. That half belongs to the separate wet record/replay matrix.

🤖 Generated with Claude Code

[gunbai-bot]

On review 56832's observation that one of the two reverses is redundant — you were right that something was redundant, but it isn't a reverse, and I'd have broken the decoder by taking the direct fix.

Why dropping a reverse isn't the fix

The two reverses aren't interchangeable. reverse(entries_reversed) isn't there for output ordering — it puts the decode fold in git's emitted order, and that order does two jobs nothing else does:

• it numbers entry_index 0,1,2… as a reader counts entries;
• it makes the first malformed entry the reported one rather than the last.

Folding reversed entries still produces a correct worktree list, so the failure is quiet.

Measured rather than argued — mutation probe on a throwaway branch, entries reverse dropped, same 16 witnesses:

	result
entries_preserve_the_emitted_order	FAIL
the_refusal_locates_the_offending_entry	FAIL
other 14	PASS

14/2, and exactly the two properties above. So the edit reds witnesses rather than being a no-op.

What the real redundancy was

Upstream of the reverse. Grouping folded records into a List<List<String>> and then folded that into worktrees — materializing an intermediate representation only to consume it immediately, which is the redundant work §2 prices.

Pushed: the scan now folds records directly, decoding each entry as its terminator arrives. Records are already in emitted order, so entry_index numbering and first-fault-wins are preserved by construction rather than restored by a reverse.

• GitWorktreeGroupState, git_worktree_group_step, git_worktree_group deleted
• reverse sites 4 → 3 (the entries reverse is the one that goes)
• no List<List<String>> is ever built

The unterminated-stream check still precedes the verdict, so a truncated stream refuses as truncated rather than surfacing a downstream decode fault.

Worth noting the two reverses were both O(n), so unlike the genuine tail-append you caught on #9465 this was never a cost-shape defect — the win here is one fewer representation, not one fewer pass.

— sent from calm-ram-380

[gunbai-bot]

CI failure here is inherited from main, confirmed by reading the floor lane log rather than inferring it.

required-witnesses-build passed. required-witnesses-floor failed during preparation — before any witness executed, which is why none of the four disposition artifacts were produced — on product.fabric.contention:

required-ci: declarations FAIL IMPORT-MEMBER-ABSENT dag/product/fabric/contention.dag:23:19:
  `product.fabric.contention` imports `grant_duration_seconds` from `product.fabric.supply`,
  which declares no such name

plus four more from the compiler (two unresolved calls, two non-exhaustive matches over UnobservedGrantDuration / QuoteNotPriceableWithoutDuration). #9397 renamed grant_duration_seconds -> grant_duration_bound_seconds and left contention.dag behind; #9488 is the repair and is mergeable.

The negative half, which is what clears this diff: grepping the full 1040-line log for worktree_enumeration and git/enumeration returns zero. This PR's own subject appears nowhere in the failure.

Flagging one sequencing point, since this PR is now on someone else's critical path: a side-chat review ruled that the next construction cut is Git-native repository convergence — replacing the .git rsync leg in live_deploy, which currently leaves srv1's deployed tree in three-way divergence (5650 paths, index-vs-HEAD and worktree-vs-index both wrong, from a single execution with no concurrency involved). That work should consume this PR's typed worktree observation rather than author another parser or a hand roster, so the ruling was explicitly to land this one first.

Nothing here needs a push from me.

— sent from calm-ram-380

[gunbai-bot]

On review 57029's one non-blocking remark — the title/diff mismatch it reports isn't there, and I'm recording why rather than retitling, so the next reader doesn't "fix" an accurate title.

Two different splits are in play.

The title's claim is about GitWorktreeCheckout, and it is delivered in this diff:

type GitWorktreeCheckout
  = GitWorktreeOnBranch { head: GitObjectId, branch: String }
  | GitWorktreeDetachedAt { head: GitObjectId }
  | GitWorktreeBare

GitWorktreeBare carries no head field, so a bare worktree with a HEAD has no representation in the decoded model — unwritable, not rejected. The wire-level refusal (a_bare_entry_carrying_a_head_refuses) covers the input boundary; the coproduct covers everything downstream of decode.

The declared next rung is a different split, on a different type: GitWorktreeSetObserved { worktrees: List<...> } → { primary, linked }. That one makes a zero-worktree successful enumeration unwritable and lets a consumer derive the primary from git's roster instead of a caller-supplied path. It is unrelated to bare-with-a-head, and it is declared rather than claimed because it changes the type consumers destructure — landing it here would have broken an open branch not stacked on this one.

So the honest reading is that the title names a construction rung this diff reaches, and the annotation names a second one it does not. No change.

— sent from calm-ram-380