Docs

Workspaces y worktrees

Dos problemas distintos que parecen lo mismo: «más de un checkout». Un workspace ejecuta un comando sobre muchos repositorios. Un worktree le da a un repositorio varios checkouts a la vez.

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: muchos repositorios, un comando

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

Esta es la respuesta al bucle de shell que todo el mundo escribe una vez y luego mantiene para siempre. workspace status es el que merece estar en la rutina de cada mañana.

Worktrees: un repositorio, varios checkouts

Cada worktree es un directorio aparte en una rama aparte, compartiendo una única base de objetos. Un hot-fix no molesta al trabajo en curso.

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

La ubicación por defecto sale de worktree.base_dir, que es .. salvo que la cambies.

No recompilar desde cero

Un worktree recién creado no tiene node_modules, ni target, ni .env — así que lo primero que haces dentro es una compilación de diez minutos. worktree.inherit_paths los copia o los enlaza al crearlo:

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

Submódulos y 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

Cuál usar: un submódulo cuando la dependencia es una caja negra que actualizas de vez en cuando, y un subtree cuando la parcheas en local y quieres una única historia coherente. subtree es una envoltura fina sobre git subtree y necesita git instalado; submodule es nativo.