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.
- The built-in exclusion list is fixed:
node_modules, __pycache__, venv, .venv,
target/debug, target/release, target/rust-analyzer, target/criterion.
- Nothing in Settings,
settings.json or client-settings.json adds to it.
.gitignore is honored by the underlying ignore crate only inside a git
repository. Workspaces that are Subversion working copies, plain directories, or
anything else non-git get no benefit from it.
.ignore works, and a custom filename .jj.ignore appears to be registered as well,
but neither is mentioned anywhere in docs/user/. I only found them by reading strings
in 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.
| Level |
Files |
| Total in tree |
655098 |
Under node_modules (already excluded by T3) |
478681 |
| Effectively scanned |
146377 |
Of which .svn |
7913 |
Adding common build and VCS output directories (build/, .gradle/, platforms/,
obj/, bin/, Library/, Temp/, packages/, .git/) to an ignore file brings the
walked 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
- Document the ignore-file mechanism in
docs/user/. State which file names are
read, and state clearly that .gitignore requires a git repository. This alone would
have saved the whole investigation.
- Add
.svn and .hg to the built-in list. Both hold VCS metadata plus, in
Subversion'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 .gitignore regardless of whether a git
repository is present, since in a T3 workspace the file expresses intent about the
directory either way.
Environment
- T3 Code 0.0.40 (Alpha), installed via
winget install T3Tools.T3Code
- Windows 10 Home 19045
- Workspace is a Subversion working copy, not a git repository
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