From Emacs Redux · Bozhidar Batsov · · 2m
Git worktrees, discovered by way of AI agents
A decade of ignoring git worktrees ended when coding agents started littering the projects folder with siblings.
In brief
A decade of ignoring git worktrees ended when coding agents started littering the projects folder with siblings. A worktree is a second working directory on the same repo, so two things can happen at once without stashing, switching, or rebuilding. Originally reported by Emacs Redux.
Ten years, never needed them
Worktrees have shipped with git since 2.5 in July 2015. Feature branches covered everything: branch, work, merge, delete, repeat.
“They've been part of git for a decade and I never once needed them.”
AI agents forced the introduction
Claude Code spins up a worktree per task so several agents can share a repo in parallel. The projects directory filled with cider-this and cider-that siblings.
“Suddenly my projects directory was full of cider-this and cider-that siblings”
One directory, one branch
A branch is a free pointer to a commit, but the repo has a single working directory. Two branches means stash, check out, do the thing, check out back, unstash.
A second checkout, shared guts
git worktree add ../cider-smart-targeting -b smart-form-targeting gives you a full checkout elsewhere. Objects, refs, stashes and remotes stay shared, so it is not a clone.
“fetching in one is fetching in all”
When two things overlap
A long test run on one branch while you code on another. Reviewing a PR without touching your half-done work. Agents working in isolation.
The price is untracked files
Your files live on disk more than once, and anything git does not track comes with you. Dependencies, node_modules and build caches get rebuilt per worktree.
“Worktrees are one of those features you don't miss until your workflow changes.”
Jujutsu skips the problem
In jj the working copy is a commit, snapshotted as you go. No staging area, no stash, no uncommitted state to lose, plus jj workspace and an undoable operation log.
“the most interesting thing happening in version control right now is Jujutsu”
Magit hides it behind Z
Z b checks out a branch in a new worktree, Z c makes branch and worktree together, Z g jumps between them, Z m moves, Z k deletes.
“The best part is that there's nothing else to learn.”
List them in the status buffer
Add magit-insert-worktrees to magit-status-sections-hook and every status buffer lists the repo's worktrees. Hit RET on one to jump there.
Name them as siblings
Put cider-smart-targeting next to cider, never nested inside it, since nesting confuses grep and find. Delete with Z k, and git worktree prune cleans up after a manual rm.
The key point
A worktree is a second working directory on the same repo, so two things can happen at once without stashing, switching, or rebuilding.
