# Git worktrees

Index a linked git worktree without re-indexing from scratch, by seeding from the base checkout and catching up incrementally.

Run [`repowise init`](https://docs.repowise.dev/cli/indexing#repowise-init) or
[`repowise update`](https://docs.repowise.dev/cli/indexing#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.

```bash
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:

```text
[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](https://docs.repowise.dev/auto-sync#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

| Flag | Effect |
|------|--------|
| `--no-seed` | Force a cold full init inside a worktree, skipping auto-detection entirely. |
| `--seed-from <path>` | Seed from an explicit checkout instead of the auto-detected base. Useful for unusual layouts, such as seeding one full clone from another. All the same validations apply. |

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

## Uncommitted edits

A branch in a worktree is often mid-edit. `repowise update --working-tree`
brings uncommitted changes into the index without a commit: symbols,
edges and pages for the edited files are current, and the history and
analysis phases are skipped, so a small edit refreshes in seconds. MCP
responses mark which served files carry uncommitted edits.

## 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.

> **Note**
>
> Auto-detection applies to single-repo worktrees.
> Workspace-member auto-seeding is planned. See
> [Workspace setup](https://docs.repowise.dev/multi-repo/workspace-setup) for the multi-repo
> side of things.

## Troubleshooting

| Message | What it means |
|---|---|
| `does not share the same initial commit` | The seed source is an unrelated repository, or a shallow clone whose history was truncated. Run a full `repowise init` instead. |
| `is not an ancestor of worktree HEAD` | The base's index was built on a branch that has diverged from the worktree's branch. Run `repowise update` in the base checkout, or let it fall through to a full init. |
| `missing .repowise state/db` | The base checkout was never indexed, or was indexed with a version that predates the current store layout. Index the base first, and worktrees created afterwards seed instantly. |