Git worktrees

Run repowise init or repowise update inside a fresh git worktree and it just works. No flags, no path arguments, no second full index. repowise notices the directory is a linked worktree, copies the base checkout's .repowise/ index, and then runs an incremental update so only the files that differ on your branch get re-processed.

repowise init        # seeds from the base checkout, then runs an incremental update
repowise update      # same: an unindexed worktree seeds itself first, then updates

You get a one-line notice when it happens:

[worktree] Linked worktree of /path/to/base detected; seeding its index.

The base checkout is derived from git's own metadata, so you never pass a path. That makes the path safe for automation: a post-commit hook or a coding agent running repowise update inside an unindexed worktree gets seed-then-update instead of an error.

The seeded index belongs to the worktree. The copied database is re-pointed at the worktree, so later updates, searches, and MCP queries stay coherent. Deleting the worktree deletes its index along with it, and the base checkout is never modified.

When seeding is skipped

Auto-seeding fires only when all four of these hold. Otherwise repowise falls back to a normal full init and prints a one-line notice explaining why:

• The directory is a linked worktree (its .git is a file pointing into the base checkout).
• The worktree has no .repowise/state.json yet, so an already-indexed worktree is left alone.
• The base checkout has a healthy index (state.json plus wiki.db).
• Base and worktree share the same initial commit, and the base's last synced commit is an ancestor of the worktree's HEAD.

Overrides

--seed-from also works outside worktrees: any two checkouts of the same repository qualify, as long as they share history.

Workspaces

--seed-from maps workspace members by relative path, so seeding a workspace root from another workspace root seeds each member repo from its counterpart.

Troubleshooting