Gitorii
Source

Docs

Workspaces and worktrees

Two different problems that both look like "more than one checkout". A workspace runs one command across many repositories. A worktree gives one repository several checkouts at once.

workspace one command, many repositories workspace sync ~/repos/api ~/repos/worker ~/repos/frontend own .git own .git own .git three histories, unrelated worktree one repository, many checkouts ~/api main ~/api-hotfix 0.7 one .git objects shared one history work in progress the hot-fix, undisturbed

Workspaces: many repositories, one command

torii workspace add backend ~/repos/api
torii workspace add backend ~/repos/worker
torii workspace list
torii workspace status backend                # status across all of them
torii workspace save backend -m "wip" --all   # commit every repo that has changes
torii workspace sync backend                  # pull and push all of them
torii workspace remove backend ~/repos/api
torii workspace delete backend

This is the answer to the shell loop everyone writes once and then maintains forever. workspace status is the one worth putting in your shell prompt's morning routine.

Worktrees: one repository, several checkouts

Each worktree is a separate directory on a separate branch, sharing one object database. A hot-fix does not disturb work in progress.

torii worktree add -b feature/auth      # new branch, checked out at ../<repo>-feature-auth/
torii worktree add ../hotfix release/0.7
torii worktree list                     # branch, clean/dirty, ahead/behind
torii worktree open ../hotfix           # a shell inside it
torii worktree remove ../hotfix         # snapshot taken first
torii worktree remove ../hotfix --force # even if dirty
torii worktree prune

The default location comes from worktree.base_dir, which is .. unless you change it.

Not rebuilding from scratch

A fresh worktree has no node_modules, no target, no .env — so the first thing you do in it is a ten-minute build. worktree.inherit_paths copies or symlinks those in at creation:

torii config set worktree.inherit_paths ".env,target,node_modules"

Submodules and subtrees

torii submodule add git@github.com:owner/lib.git vendor/lib --branch main
torii submodule update --init
torii submodule foreach 'cargo build'
torii submodule remove vendor/lib      # deregisters and scrubs all four state locations

torii subtree add  --prefix=vendor/lib <url> main --squash
torii subtree pull --prefix=vendor/lib <url> main --squash
torii subtree push --prefix=vendor/lib <url> main
torii subtree split --prefix=vendor/lib -b lib-split

Which to use: a submodule when the dependency is a black box you bump occasionally, a subtree when you patch it locally and want one cohesive history. subtree is a thin wrapper over git subtree and needs git installed; submodule is native.