index_repository ignores .git/info/exclude and core.excludesFile inside linked git worktrees

[Naam]

Version

codebase-memory-mcp 0.8.1 (also reproduces on main @ 9169f46, built from source)

Platform

macOS (Apple Silicon)

Install channel

GitHub release archive / install.sh (0.8.1); Built from source (main)

Binary variant

standard

What happened, and what did you expect?

#489 and #499 taught the indexer to honor .git/info/exclude and the global core.excludesFile, but only for an ordinary checkout. Inside a linked git worktree both are dropped again, so directories you excluded there get walked and indexed.

The reason is that in a linked worktree <repo>/.git is a regular file (a gitlink, gitdir: <path>), not a directory. cbm_discover_ex() gates every per-clone ignore source on .git being a directory:

bool is_git_repo = wide_stat(gi_path, &gi_stat) == 0 && S_ISDIR(gi_stat.st_mode);

When that check is false, info/exclude and config are never read. Committed .gitignore still applies (the #510 path loads <repo>/.gitignore unconditionally), which is why only the non-committed excludes break and the gap is easy to overlook.

This is the same class of problem #489 was opened for (agent/sandbox worktrees blowing up the index), just from the other side: #489 indexes the main repo whose worktrees sit under an info/exclude path; this is indexing the worktree itself, which is exactly what branch-per-worktree agent workflows do. I hit it on a Zephyr firmware worktree where indexing pulled in ~31k nodes of build/ output that git check-ignore reports as ignored.

Expected: a worktree honors info/exclude and core.excludesFile the same way an ordinary checkout does.

Reproduction

T=$(mktemp -d); cd "$T"
git init -q main && cd main
echo 'def included(): return 1' > main.py
git add -A && git -c user.email=t@t -c user.name=t commit -qm init

# add a linked worktree, then exclude build/ ONLY via the shared info/exclude
git worktree add -q ../wt -b feat
echo 'build/' > .git/info/exclude
mkdir -p ../wt/build
echo 'def build_artifact(): return 2' > ../wt/build/gen.py

# git agrees build/ is ignored inside the worktree:
( cd ../wt && git check-ignore build/gen.py )   # -> build/gen.py
head -1 ../wt/.git                                # -> gitdir: .../worktrees/wt   (a file, not a dir)

codebase-memory-mcp cli index_repository "{\"repo_path\":\"$T/wt\"}"

Actual: the index summary has no build in excluded, and build/gen.py is indexed:

"nodes":8        # main.py + build/gen.py
# search_code build_artifact -> "file":"build/gen.py","total_results":1

Expected: build/ excluded, only main.py indexed (matching git check-ignore).

For contrast, the identical layout in a normal checkout (info/exclude in a non-worktree .git/) excludes build/ correctly, so the divergence is specific to the worktree gitlink.

Confirmations

• I searched existing issues and this is not a duplicate. (Closest are index_repository ignores .git/info/exclude (only .gitignore honored) → indexes excluded worktrees → OOM #489 and index_repository silently ignores git global core.excludesFile — globally-excluded files are indexed #499, both closed and both fixed for ordinary checkouts only; this is the linked-worktree follow-up.)
• My reproduction uses shareable code (a dummy snippet), not proprietary code.

[DeusData]

Thanks for isolating the linked-worktree .git file case. I’ve triaged this under #398 and #396. The fix should resolve the gitdir pointer and read the right per-worktree/common-dir excludes, with a regression test that matches git check-ignore for the same path.

[Naam]

Thanks for the quick triage, much appreciated. That lines up with what #683 implements: when .git is a gitlink file it parses gitdir:, follows <gitdir>/commondir to the shared dir, and reads info/exclude and config from there. A plain .git directory resolves to itself, so ordinary checkouts are unaffected.

The regression test discover_worktree_info_exclude sets up a worktree where build/ is excluded only through info/exclude, then asserts it isn't indexed. It fails before the change (count==2, build/ leaks) and passes after, matching what git check-ignore reports for that path. There's also discover_worktree_committed_gitignore for the committed-.gitignore case, and the full suite stays green under ASan/UBSan.

No worries at all if you'd rather fold it into the #398/#396 work differently. Glad to revise whatever fits your plan best.