Important
If you already have a git worktree flow that works for you, stick with it. Stooges is a (simple) alternative to worktrees, but if they work for you, go for it!
If you work with AI coding agents, run long test suites, or just want to context-switch between tasks without stashing, you need multiple copies of your repo. Your options:
| Disk cost | Independent? | Tooling | |
|---|---|---|---|
| Plain copies | Full duplicate | ✅ Yes | None — you manage them yourself |
| Git worktrees | Shared .git |
❌ Shared index & lock files | Built into git |
| Stooges | Copy-on-write (near zero) | ✅ Yes | CLI for create, sync, rebase, cleanup |
Worktrees are great until they aren't — a rebase in one worktree locks the index for all of them, and some tools (like certain editors and AI agents) get confused by the shared .git structure. Plain copies work but waste disk space and give you nothing to manage them with.
Stooges gives you fully independent repo clones that take almost no extra disk space, with a small CLI to create, sync, and clean them up.
APFS (macOS) and some Linux filesystems support copy-on-write cloning — instant copies that share disk blocks with the original and only use extra space as files diverge. On macOS this has been the default since High Sierra (2017). For Linux, reflink support has been around for a while but varies by filesystem. stooges doctor will tell you if your system supports it.
curl -sSL https://raw.githubusercontent.com/scottwater/stooges/main/install.sh | bashOr with Go:
go install github.com/scottwater/stooges/cmd/stooges@latest# make sure your system supports copy-on-write cloning
stooges doctor
# initialize — this restructures your repo directory
stooges initYou can also just run stooges with no arguments for an interactive guided mode.
Running stooges init inside your repo restructures the directory:
# Before # After
myproject/ myproject/
├── .git/ ├── .stooges/ ← your original repo, locked read-only
├── src/ ├── larry/ ← clone workspace
├── package.json ├── curly/ ← clone workspace
└── ... └── moe/ ← clone workspace
- Your repo contents are moved into a
.stoogesdirectory - The
.stoogesdirectory is locked read-only (so you don't accidentally edit the base) - Three default workspaces are created as copy-on-write clones
If you don't want the defaults, specify your own with --workspace:
stooges init --workspace agent1 --workspace agent2Changed your mind? stooges undo puts everything back the way it was.
# create a new workspace with its own branch
stooges add feature-x -b
# work normally inside it
cd feature-x
# edit, commit, push — it's a full independent repo
# keep workspaces up to date with your base branch
stooges rebase
# done? push your branch and delete the workspace
cd ..
trash feature-xYou can add a new workspace at any time with stooges add. The -b flag creates a branch named after the workspace, or use --branch name for a specific branch name.
Use --track <branch> to track origin/<branch> in a newly created workspace (optionally with --branch <local-name>).
# fetch latest from remote into the base repo and relock it
stooges sync
# sync + prune stale remote-tracking refs
stooges clean
# sync base + rebase all workspace branches onto the base branch
stooges rebase --pruneIf you need to manually edit the base repo (e.g., resolve something), use stooges unlock and stooges lock to temporarily toggle the read-only protection.
stooges doctor # check platform support
stooges --version # print installed version
stooges upgrade # replace current binary with latest release
stooges # guided interactive mode
stooges init # initialize workspace layout
stooges add # create missing default workspaces
stooges add moe # create one workspace
stooges add bob -b # create workspace + branch named "bob"
stooges add bob --branch x # create workspace + branch named "x"
stooges add bob --track feature/foo # track origin/feature/foo
stooges add bob --track feature/foo --branch foo # local "foo" tracking origin/feature/foo
stooges sync # sync base repo from remote
stooges clean # sync + prune stale refs
stooges rebase --prune # sync + rebase workspaces onto base
stooges list # list base + workspaces with branch and latest commit
stooges undo --yes # tear down workspace layout (destructive)init— initialize the workspace layoutadd— create workspacessync— fetch & update the base repoclean— sync + prune stale remote-tracking refsrebase— sync base + rebase workspace brancheslist(ls) — show base + managed workspaces with git head infounlock/lock— toggle read-only protection on the baseundo(alias:remove) — tear down and restore original layoutdoctor— check platform support and workspace healthversion(or--version) — print installed versionupgrade— install the latest GitHub release over the current binary- no args — interactive mode
When a newer release exists, Stooges prints a one-line upgrade notice at most once per 24 hours:
Update available: v0.79 (installed v0.78). Run: stooges upgrade