Module worktree_copy_forward 

Which forwarded invocations the copy applies to, and the child run that carries its settlement lease. What: Running a forwarded Git command through the linked-worktree ignored-state copy: which invocations the copy applies to, and the child-process run that carries the settlement lease. Why: A command that creates or moves worktrees must stay under the settlement lock while real Git runs and the ignored state is copied, and a command run from a linked worktree must first recover an interrupted copy; replacing the process with Git would drop both duties, so these invocations run Git as a child. The main checkout is a source only for the configured rules file, so it takes this path only when the command creates a worktree and the configuration names that file.

In TS you’d write (pseudocode):

await runGitWithWorktreeCopy({ args, gitPath, identity, command, environment });

Structs

CopyFacts

What: Everything the copy needs to know about one forwarded invocation, decided before Git starts. Why: The plan decides that the copy applies; the run performs it with real Git and the process environment.

Enums

ForwardedRun

What: How one forwarded run ended. Why: Only a run that failed before or after Git needs its own text; otherwise the status is Git’s.

Functions

copy_applies

What: Whether the copy applies to an invocation. Why: Linked worktrees and bare repositories always take the lifecycle (recovery, lease check, creation); the main checkout only when it creates a worktree and has paths to hand over, so its other commands keep their plain forwarding and cost no filesystem reads.

run_forwarded_git

What: Runs the forwarded Git command, settling the ignored-state copy around it when one applies. Why: Git’s status is the answer unless the copy failed: a copy failure after a successful Git is status 2, after a failed Git it keeps Git’s status, and a failure of the lifecycle itself is status 2, each with its message.