[Suggestion]: index files inside linked git worktrees that live under repo root (like .worktrees/)

[AndrewP-GH]

Which fff frontend(s)?

MCP server (fff-mcp)

What problem are you trying to solve?

In short

I use fff-mcp daily and I am very thankful for it — it became part of my hands. But there is one case where it cannot help me, and I think it is worth fixing.

When I start fff-mcp at the root of repository, it does not see files that live in linked git worktrees nested under this root. Typical layout in our team is <repo>/.worktrees/<branch>/. We keep .worktrees/ in .gitignore on purpose, so that git status stays clean. And here is the whole problem: fff respects .gitignore and .git/info/exclude honestly, so these files become invisible.

My environment

• Tool: fff-mcp (the MCP build of fff), one positional argument [PATH]
• Host: Claude Code. It starts MCP server once per session, and sets working directory of server equal to directory from where editor was launched.
• OS: macOS (darwin)

What happens now

1. fff-mcp decides its scan root through Repository::discover(&base_path) → repo.workdir() (you can see it in crates/fff-mcp/src/main.rs). When I am already inside a worktree, this resolves to that worktree workdir, and then everything works perfectly — so per-worktree start is not a problem.
2. But when I start from the main checkout, the root becomes the main workdir. Nested worktrees under .worktrees/ are thrown away, because they are written in .gitignore (and frequently in .git/info/exclude too), and fff obeys both of them.
3. In CLI there is no --no-ignore, and in FffCreateOptions (crates/fff-c/include/fff.h) there is no field to switch ignore off. PATH is single — so no second root either.

So the conclusion is simple and a little sad: a session that started at the main checkout will never see the worktree files, and one instance cannot serve the main checkout and the worktrees together.

Why this is important for me (and possibly not only for me)

Worktrees nested under the repo (<repo>/.worktrees/<branch>/) are not exotic —
for teams that hold many branches checked out at the same time. We put .worktrees/ into .gitignore exactly to keep git status quiet, and exactly this gesture is what hides them from fff. Very often I open one session at the root and then walk into a worktree in the middle of work — and from this moment fff, nailed to the main root since launch, becomes blind to the very files I am editing. It is a pity, because the engine itself is fast and good.

Proposed solution

No response

[AndrewP-GH]

Also I checked that a worktree on its own is fully indexable: standing inside <repo>/.worktrees/<branch>, git reports around 4k tracked files, and none of them are ignored relative to that root. So the limitation is purely about reaching the nested worktree from the parent root — not about worktrees being impossible to index.

[dmtrKovalenko]

Yup this is on my list to do for a while! Will try to deliver this ASAP