Expand description
The landing lock a landing attempt takes, with the recovery every acquisition runs first.
What:
The per-worktree landing lock a landing attempt takes, and the recovery every acquisition runs first.
Why:
A crashed landing must be resolved before another landing moves the ref or the index, so the lock is acquired
and then dead landings are recovered under it (src/policy-engine/commit-landing-lock.ts).
An invocation nested under the holder, proven by an inherited landing lease, proceeds under its ancestor’s lock.
In TS you’d write (pseudocode):
await using lock = await acquireLandingLock({ gitPath, cwd, registryRoot });Functions§
- acquire_
landing_ lock - What: Take the landing lock and recover dead landings under it, or take the ancestor’s view of it. Why: The lock is released again when recovery fails before the caller receives it.
- acquire_
reserved_ lock - What: Take the landing lock once no other transaction’s reservation stands in the way. Why: The reservation is checked again under the lock, so a reservation granted while this landing waited is honored.
- landing_
is_ nested - What: Whether this invocation lands under an ancestor’s landing lock. Why: The ancestor’s lock is the one the reservation holder waits for, so a nested landing neither waits nor reserves.
- landing_
lock_ directory - What: The landing lock directory of one worktree’s registry. Why: The reservation and the lease checks name the same directory.