Feature request: built-in git-worktree auto-sync for --spawn worktree multi-session workflows (working hook pattern included)

Open 💬 6 comments Opened Jul 15, 2026 by mwfoutch

Description:
Running multiple concurrent sessions via --spawn worktree (or git worktree add directly), each session commits to its own branch in isolation. Nothing native keeps those branches synced with the main checkout, so fully-committed work can sit practically invisible — not visible to other sessions, to a human browsing the repo, or to anything served from the main checkout — until someone manually merges it. We hit this repeatedly running several long-lived worktree sessions against one shared repo: real work sat unmerged for hours to days more than once before anyone noticed.

What we built to work around it (holding up well over a week of real use):
A shared post-commit/post-merge hook (needs both — a real non-fast-forward merge fires post-merge, not post-commit) that:

  1. After every commit in a worktree, tries a fast-forward-only merge of that branch into the main checkout. Fast-forward only, never forces or resolves a real conflict itself.
  2. If that's blocked only because the main checkout moved ahead in the meantime (not a real conflict), pulls the main checkout in first, then retries the forward — still fully automatic, still conflict-free by construction.
  3. If neither succeeds, it's a genuine divergence. Instead of a generic "needs manual merge," we run a read-only git merge-tree --write-tree --name-only to report exactly which files actually conflict, versus it just being a mechanically-blocked-but-content-clean gap.
  4. Writes a single, idempotent pending-merge notice (keyed to branch name, so concurrent worktrees don't clobber each other's notices) somewhere visible, so anyone can immediately see what's diverged and how serious it is.

One sharp, non-obvious bug worth flagging for anyone attempting this themselves: if that notice is left uncommitted in the main checkout's working tree, it silently blocks the next legitimate fast-forward touching the same file — the status mechanism becomes its own blocker. Fix: commit the notice immediately, never leave it sitting uncommitted.

Suggested feature:
Since --spawn worktree is already first-class, an opt-in "auto-forward my worktree toward the main checkout, fast-forward only, tell me clearly when it can't" mode feels like it belongs natively rather than everyone hand-rolling this. Happy to share the actual hook script — fully working, just needs genericizing from our own repo layout.

View original on GitHub ↗

This issue has 6 comments on GitHub. Read the full discussion on GitHub ↗