Module branch 

Lineage identity and its lifecycle (§15.2, §15.4).

The read half of branching shipped first, at 0.14.2 through 0.14.6: the ledger tables carry a branch_id, crate::graph::TraversalBuilder::on_branch resolves along the ancestry, and 0.14.6 bounded that resolution by the fork point (D-223). Nothing in that half could create a lineage — only raw SQL could, which is why 0.14.6 could repair the read’s semantics without breaking anyone. This module is the other half: the name, and the one write that registers it.

Why the read shipped first, and why that ordering is not an accident

A write that creates something unreadable is the worse order. Had fork() landed at 0.14.2, every branch created between then and 0.14.6 would have been readable only through a query that silently absorbed its parent’s later writes — and the repair would have been a semantic break on stored data rather than a correction to an unreachable path. That is D-160 → D-174’s ordering, applied a third time and recorded in D-223.

Structs

Branch

One row of branches: a lineage, its parent, and where it was cut.

BranchId

A validated lineage name.

BranchView

One lineage’s handle on the ledger (§15.4, 0.14.9, D-226).

Divergence

One belief a holds that b does not (§15.4, 0.14.11, D-228).

Constants

MAX_BRANCH_ID

Longest accepted lineage name.