Replaying: rebuilding branches from patch files🔗

The FORMAT document describes what the files are; this one describes how a tool turns them back into git commits, exactly. Any implementation following these steps reproduces the stored branch SHA-exact.

For each patch name in series order, maintaining a map from reference to replayed SHA (seeded with BASE -> the STACK's base):

1. Parse the patch file. Resolve each parents reference through the map; an unknown reference is an error (series order guarantees parents were replayed first).
2. Read the first parent's tree into a scratch index (no worktree is required, ever).
3. If the diff section is non-empty, apply it to that index (git apply --cached --binary --whitespace=nowarn; the explicit whitespace flag keeps a target repo's own apply.whitespace from rewriting or refusing recorded bytes). An apply failure is an error: the recorded base is the only supported target.
4. Write the resulting tree.
5. Reassemble the raw commit object: tree line, one parent line per resolved parent, then the stored header block verbatim, a blank line, and the message bytes (dropping the final newline if the message-no-final-newline directive was declared). Hash and store it (git hash-object -t commit -w). Record name -> SHA in the map.

The final SHA is the replayed branch tip. When the STACK records a tip, verification compares against it; a STACK without one can still be replayed, just not cross-checked.