Search, semantic, and symbol disk caches are keyed by project_cache_key(), which is based on the repo's root commit. That's deliberate: the same repo cloned anywhere produces the same key. The side effect is that linked worktrees of one repo share that key too, even though their on-disk state differs (absolute paths, mtimes, generated and ignored files, uncommitted edits). Two worktrees end up reading each other's cache, refreshing it in memory, and skipping the write back, so neither one keeps a warm cache.
Use case
If you use git worktree to work on several branches at once, cache reuse drops to almost nothing. Giving each linked worktree its own disk cache, while keeping project identity stable across clones, fixes the churn.
Search, semantic, and symbol disk caches are keyed by
project_cache_key(), which is based on the repo's root commit. That's deliberate: the same repo cloned anywhere produces the same key. The side effect is that linked worktrees of one repo share that key too, even though their on-disk state differs (absolute paths, mtimes, generated and ignored files, uncommitted edits). Two worktrees end up reading each other's cache, refreshing it in memory, and skipping the write back, so neither one keeps a warm cache.Use case
If you use
git worktreeto work on several branches at once, cache reuse drops to almost nothing. Giving each linked worktree its own disk cache, while keeping project identity stable across clones, fixes the churn.