Explain how wt merge works

Worktrunk's wt merge takes a finished branch to main in one command. The film draws each step from the flags below it, so ticking --no-ff or a failing test re-plots the run. Tap or hover a commit, branch, worktree or hook to read its details; Inspect cycles through them. Alt-click a part to comment on it.

1. Before

   A branch in its own worktree, with commits and perhaps edits not yet committed. Main may have moved on since the branch forked.

2. 1 Commit

   Uncommitted edits become a commit of their own. The default run skips this, because the squash stages them itself.

3. 2 Squash

   Every commit since the fork, plus any edits, becomes one commit. The old tip is backed up to refs/wt-backup/<branch> first, so the squash can be undone.

4. 3 Rebase

   The work is replayed onto main's current tip, which gives it new hashes. A conflict stops the merge here, with the rebase left open to resolve.

5. 4 Pre-merge hooks

   Hooks from .config/wt.toml run on the exact tree that will land, as local CI. A failure aborts, and main never moves.

6. 5 Merge

   Main fast-forwards to the branch tip, so history stays linear. --no-ff records a merge commit instead.

7. 6 Pre-remove hooks

   A last hook before the worktree is deleted; if it fails, the worktree stays.

8. 7 Cleanup

   The worktree and branch are removed in the background, and the shell lands in main's worktree.

9. 8 Post-merge hooks

   Background hooks run from main after the prompt is back.

10. After

    Where the run ended, and what it did.