Module worktree_add_binding 

The binding of a git worktree add to the directories Git made for it, its record, and the check that the binding holds. What: The binding of one git worktree add to the objects real Git made for it (the destination directory and the administrative directory that registers it), the record that carries the binding, and the check that the binding still holds. Why: The wrapper completes an add in place, through the bound objects, and never deletes or unregisters a worktree: a path can be changed by another process between any check and any act, so no pathname or identity recorded earlier proves the right to remove something later. The binding is what a fast rung and the fallback checkout verify before they write into the worktree, and what the report of an interrupted add names. It is captured right after Git returned, and an add whose pair cannot be proven is left exactly as Git made it.

In TS you’d write (pseudocode):

const bound = await bindRegistration(commonDir, destination); // throws when the pair is not proven
await claim.recordBinding(bound.binding);
await verifyAssociation(bound); // throws when the objects are no longer where and what they were

Structs

Binding

What an add bound itself to: the two directories Git made and the pointer it wrote.

Bound

A binding with the two directories held open.

Enums

Recorded

What a record says about an add.

Functions

bind_registration

What: Bind an add to the directories Git just made for it, after proving that they belong together and to this repository. Why: The pointer must name an administrative directory directly below this repository’s worktrees, and that directory’s gitdir must name the pointer back; only then are the identities of both directories and the pointer bytes captured, with both directories held open. A pointer edited to name another worktree’s administrative directory fails the back-link.

decode_path

The path of a record’s text.

decode_record

What: Read the text of an add’s record. Why: A record that does not parse in full is treated as planned only when its destination field parses; anything else is unreadable and authorizes nothing.

encode_path

The text of a path for a record: hexadecimal, so that a newline in a name cannot forge a field.

path_identity

The identity of the object that the canonical path path names now, or nothing.

planned_record

The record text of a planned add.

verify_association

What: Check that the objects an add was bound to are still where and what they were: the destination and the registration still have the bound identities at their paths, the pointer still has the bound bytes, and the registration still names the pointer. Why: A write into the worktree, or a checkout by Git, must go to the exact worktree the add made; if another process moved or replaced either object, the step stops and the add is reported, with nothing changed.