Module replay_commit 

Replay: one replay of a prepared commit onto a moved target, the integrator’s replay result (replay_commit). What: One replay of a prepared commit onto a moved target, as the landing loop runs it outside both locks: shared paths, capture order, subsumption, the merge, and either the replayed commit or the conflict. Why: This is the replay result the integrator consumes. Revalidation after a clean merge (policies, pre-commit) and the events are the integrator’s; this function returns the data for commit-replayed, replay-headers-dropped, and concurrent-commit/replay-conflict, and the replayed tree the revalidation reads.

In TS you’d write (pseudocode):

// commit-replay.ts + commit-capture-order-replay.ts + commit-replay-subsumption.ts, composed as the landing step does

Structs

ReplayConflict

What: The replay result of an overlapping merge: the data for concurrent-commit/replay-conflict. Why: The named prepared commit stays in the object store so the user can cherry-pick it.

ReplayRequest

What: One replay’s inputs: the Git context and directories, the transaction, the commit IDs, and the signing options. Why: A struct keeps the call site short; every field is named once.

Replayed

What: The replay result of a clean merge: the replayed commit and the data for commit-replayed and replay-headers-dropped. Why: The integrator runs revalidation on tree, then emits the events and lands oid.

Enums

MergeStep

What: The result of the merge half of a replay: the merged tree and what subsumption decided, or the conflict. Why: The incumbent revalidates the merged tree before it rebuilds the commit, so the two halves are separate steps.

ReplayError

What: A replay failure: one of its steps failed, and the replay is transaction-failed rather than a conflict. Why: Each step reports its own failure type, so the integrator sees which step broke.

ReplayOutcome

What: The outcome of one replay. Why: The landing loop branches on it: a clean replay is revalidated and landed, a conflict fails without landing.

Functions

merge_replay

What: Lists the shared paths, decides capture order, settles subsumed paths and merges, naming the first landed commit that touched a conflicting path when the merge conflicts. Why: Every step runs outside both landing locks in the shadow store; the merged tree is revalidated before the commit is rebuilt on it.

rebuild_replay

What: Rebuilds the prepared commit on a tree, with the target that won as its parent. Why: The tree is the merged tree, or the tree revalidation settled; a signed commit is re-signed.

replay_commit

What: Replays the prepared commit onto current: lists the shared paths, decides capture order, settles subsumed paths, merges, and rebuilds on a clean merge; on a conflict, names the first landed commit that touched a conflicting path. Why: Every step runs outside both landing locks in the shadow store, so the landing loop can take the locks only for the revalidated commit it then lands.