Observed
Common metarepo pattern: a service Taskfile contains cd ../sibling-repo && task build (or similar relative-path navigation across repos). symlink_dirs only replicates a directory from the source checkout into the worktree. It does NOT make ../sibling-repo resolve to anything sensible from inside a worktree at .worktrees/feat/<slug>/<repo>/.
Today's only fixes are:
- Modify the inner repo's Taskfile to use absolute or env-based paths (often impossible — shared with non-mship users).
- Manually create symlinks after every spawn (loses with
mship prune).
Proposal
Per-repo external_symlinks field in mothership.yaml:
repos:
api:
path: ./api
external_symlinks:
../shared: /abs/path/to/shared # absolute target
../auth: ${MSHIP_WORKSPACE}/auth # workspace-relative via env
../infra: workspace://infra # workspace-relative shorthand
On mship spawn:
- For each
external_symlinks entry, create a symlink at <worktree>/<key> pointing at the resolved target.
- Refuse to overwrite existing files at the symlink path.
- Symlink absent? Drop it on
mship close cleanup.
Why substrate-shaped
This is a path-management primitive — declare "this worktree needs these symlinks to function." It doesn't know anything about Taskfile syntax, language ecosystems, or methodology. Same shape as symlink_dirs, just for cross-repo paths instead of intra-repo dirs.
Acceptance
mothership.yaml accepts external_symlinks: {<rel-path-in-worktree>: <target>} per repo.
mship spawn creates the symlinks. mship close removes them.
mship audit doesn't flag the symlinks as drift.
- Refresh strategy: see companion issue (mothership.yaml changes don't refresh existing worktrees).
Related
Observed
Common metarepo pattern: a service Taskfile contains
cd ../sibling-repo && task build(or similar relative-path navigation across repos).symlink_dirsonly replicates a directory from the source checkout into the worktree. It does NOT make../sibling-reporesolve to anything sensible from inside a worktree at.worktrees/feat/<slug>/<repo>/.Today's only fixes are:
mship prune).Proposal
Per-repo
external_symlinksfield inmothership.yaml:On
mship spawn:external_symlinksentry, create a symlink at<worktree>/<key>pointing at the resolved target.mship closecleanup.Why substrate-shaped
This is a path-management primitive — declare "this worktree needs these symlinks to function." It doesn't know anything about Taskfile syntax, language ecosystems, or methodology. Same shape as
symlink_dirs, just for cross-repo paths instead of intra-repo dirs.Acceptance
mothership.yamlacceptsexternal_symlinks: {<rel-path-in-worktree>: <target>}per repo.mship spawncreates the symlinks.mship closeremoves them.mship auditdoesn't flag the symlinks as drift.Related
mship symlinks refreshor extendbind refresh).