Repository navigation
[Bug]: No documented way to exclude directories from the workspace index; .gitignore does not apply outside a git repository #10918
Description
Activity
Triage
Confirmed, not a duplicate of #10917. That issue is the hardcoded 15s scan timeout failing
projects.listEntries. This one is the missing, undocumented way to shrink what the index walks — especially outside Git.What the tree actually does
The Files panel,
@picker, and workspace search all go throughWorkspaceEntries→WorkspaceSearchIndex→@ff-labs/fff-node@0.9.4. T3 creates the finder with no ignore/exclude options:FileFinder.create({ basePath: cwd, disableMmapCache: true, disableContentIndexing: variant !== "content", aiMode: false, enableFsRootScanning: true, enableHomeDirScanning: true, })
There is no setting in Settings,
settings.json,client-settings.json, ort3.json.projects.listEntriesaccepts only{ cwd }.Built-in skips are a fixed list in FFF 0.9.4 (
crates/fff-core/src/ignore.rs):node_modules,__pycache__,venv,.venv,target/debug,target/release,target/rust-analyzer,target/criterion, plus some Windows/macOS machine-state paths. T3 does not extend it. Current FFF main still does not include.svnor.hg.Ignore files
FFF’s walker is the
ignorecrate (0.4.25in FFF 0.9.4):.gitignore/.git/info/exclude/ global gitignore apply only inside a Git (or Jujutsu.jj) root. A Subversion WC or plain directory gets no benefit. That is crate semantics, not a T3 wiring bug..ignoreis always read (WalkBuilder.ignore(true)), same syntax as gitignore, and does not require Git. The reporter’s reduction (146k → 93k) is this path..jj.ignoreis not registered as a custom filename in FFF 0.9.4. The crate treats a.jjdirectory as a VCS root so.gitignoreapplies there. Jujutsu itself still uses.gitignore.
None of this is documented in
docs/user/. FFF’s own README mentions.ignore; T3’s user docs do not.On adding
.svn/.hgFor a non-Git root FFF also sets
.hidden(true), so dot-directories such as.svnshould already be skipped (same walker condition as #8665). The 7,913.svnfiles in the report look like an independent tree walk after subtractingnode_modules, not a confirmed index inclusion. The reporter already notes this is ~5% and not the dominant cost. Adding.svn/.hgto the built-in list is still reasonable defense-in-depth; the user-facing fix is documenting.ignoreforbuild/,obj/,bin/,platforms/, and similar.Not a duplicate
Issue / PR Why it is related but distinct #10917 Timeout / hard fail. Same workspace; different fix. #4640 Silent 25k truncation on the same index. #8665 / #8670 Non-Git dot-entries hidden by .hidden(!is_git_repo).#10628 / #10686 Non-Git binaries dropped by FFF 0.9.4; open FFF 0.10.6 bump. #10380 Opposite knob: show gitignored files. #2077 / #2078 Historical @search gitignore wiring (pre-FFF). Closed.#7088 Usage transcript walk, not the workspace index. No merged fix. Open PRs above do not document ignore files or add user excludes.
Workaround
Add a
.ignorefile at the workspace root (gitignore syntax). Example for this report:.svn/ .hg/ build/ .gradle/ platforms/ obj/ bin/
Restart or refresh Files so the index rebuilds.
.gitignorein the same place will not help until the folder is a Git (or.jj) repo.Next step
- Document the ignore-file mechanism in
docs/user/(which names are read; that.gitignoreneeds a Git/Jujutsu root; that.ignoreis the supported extra file). - Optionally ask FFF to add
.svn/.hgto the built-in list, and/or honor.gitignorewithout a Git root. T3 0.9.4 has no API to pass extra patterns today. - Do not wait on [Bug]: Workspace index scan timeout of 15s is hardcoded and fails the whole Files panel with no partial result #10917, fix(server): list binary files outside Git repositories #10686, or feat(files): add a setting to show gitignored files #10380.
Labels:
documentation,enhancement,accepted,via-triage; removeneeds-triage.- addeddocumentationImprovements or additions to documentationImprovements or additions to documentationenhancementRequested improvement or new capability.Requested improvement or new capability.acceptedfeature request acceptedfeature request acceptedvia-triageFiled through npx t3 triageFiled through npx t3 triage
on Sep 9, 2026 - locked and limited conversation to collaborators
on Oct 11, 2026
The situation
On a large workspace the index scan exceeds the hardcoded 15-second deadline and the
Files panel fails completely (reported separately). The natural user response is to
exclude directories that carry no useful content. There is no supported way to do that.
node_modules,__pycache__,venv,.venv,target/debug,target/release,target/rust-analyzer,target/criterion.settings.jsonorclient-settings.jsonadds to it..gitignoreis honored by the underlyingignorecrate only inside a gitrepository. Workspaces that are Subversion working copies, plain directories, or
anything else non-git get no benefit from it.
.ignoreworks, and a custom filename.jj.ignoreappears to be registered as well,but neither is mentioned anywhere in
docs/user/. I only found them by reading stringsin
fff_c.dll.So the mechanism largely exists; it is simply undiscoverable, and the one file name most
users would reach for is the one that silently does nothing for them.
Measurements from a real workspace
Windows 10, local NTFS, Subversion working copy, T3 Code 0.0.40.
node_modules(already excluded by T3).svnAdding common build and VCS output directories (
build/,.gradle/,platforms/,obj/,bin/,Library/,Temp/,packages/,.git/) to an ignore file brings thewalked tree to 93482 files. The index scan then completed in 1503 ms instead of hitting
the 15-second deadline.
One caveat on that number, because it would be easy to over-read: the OS
directory-metadata cache was warm when it was taken. An equivalent walk over the same
tree took 100.8 s cold against 9.9 s warm, so cache state is worth about a factor of ten
here and the exclusion list about a factor of three. The exclusions are a real
improvement, but they are not by themselves the difference between 15028 ms and 1503 ms.
Two suggestions
docs/user/. State which file names areread, and state clearly that
.gitignorerequires a git repository. This alone wouldhave saved the whole investigation.
.svnand.hgto the built-in list. Both hold VCS metadata plus, inSubversion's case since 1.7, a pristine duplicate of the working tree. It is 5 % here
rather than the dominant cost, so this is a small win, not a fix — but it is content
that can never be wanted.
A third option worth considering is honoring
.gitignoreregardless of whether a gitrepository is present, since in a T3 workspace the file expresses intent about the
directory either way.
Environment
winget install T3Tools.T3Code