TortoiseGit Icon Overlays: Scoping the Shell Extension Instead of Removing It
TortoiseGit's icon overlays are usually what makes Explorer slow in large repos. Here's how the status cache and the overlay include/exclude lists work, and when to scope them instead of uninstalling.
18 Oct 2025, 20:35 UTC

The symptom is Explorer, not Git
Open a repository with a couple hundred thousand files, or one sitting on a mapped network drive, and right-clicking a folder can take seconds. The address bar hangs, the tree repaints in chunks, and the whole desktop feels sticky. Meanwhile git status in Git Bash comes back promptly. The expensive part is not Git — it is the shell extension drawing status icons for every item Explorer is about to display.
The practical fix is usually not uninstalling TortoiseGit. It is scoping the icon overlay cache so it only does work in the directories where you actually look at status. Two controls in the settings dialog do most of that.
What actually runs when you browse a folder
TortoiseGit installs two cooperating pieces: a shell extension DLL loaded into Windows Explorer, and a separate status cache process, TGitCache.exe. When Explorer is about to draw a folder, the extension asks the cache for each item's status; the cache does the repository lookups and remembers the answers.
Two constraints make this expensive at scale:
- Overlays are requested per item, per folder view. A folder with 50,000 entries is far worse than a folder with 50.
- Windows loads only a limited number of icon overlay handlers — historically around 15, with the OS reserving some — so TortoiseGit's overlay types (modified, conflicted, added, ignored, and others) compete for those slots with cloud-sync clients and other shell extensions.
Version assumption: the settings described below are from TortoiseGit 2.x. Dialog labels and option names have shifted across releases, so confirm the wording in your installed build before documenting or scripting it.
The decision: scope overlays to where you work
Open Settings → Icon Overlays from the TortoiseGit context-menu submenu. Three settings matter:
- Status cache. Current 2.x builds offer Default, Shell and None. Default uses the out-of-process
TGitCache.exe. Shell performs the lookup inside Explorer itself — if the cache process is what is stalling, this does not fix it, it moves the stall into Explorer. None disables overlays entirely while keeping the context menu, which is a legitimate choice for a huge or network-hosted repository. - Include paths. When this list is non-empty, overlays are shown only under the listed paths. This is the strongest lever: name the two or three directories you actively edit.
- Exclude paths. One path per line. The best candidates are dependency and build output trees —
node_modules,target,bin,obj,.venv,vendor.
These lists control overlays only. They do not change what Git tracks, and they do not remove anything from the context menu.
Worked example: a monorepo plus a network share
Scenario: D:\work\monorepo (roughly 180k files) and \\fileserver\projects are both Git working trees, and Explorer is sluggish in both. These are per-user settings, so no administrator rights are needed.
- Right-click any folder, then TortoiseGit → Settings → Icon Overlays.
- Leave Status cache on Default unless you have a specific reason to change it. Treat Shell as a diagnostic step, not a fix.
- In Include paths, add the directories you actually work in, for example
D:\work\monorepo\srcandD:\work\monorepo\docs. - In Exclude paths, add the heavy generated trees, for example
D:\work\monorepo\node_modulesandD:\work\monorepo\target. - Add
\\fileserver\projectsto Exclude paths if you do not need overlays on the share at all — per-item network round trips are the worst case. - Apply, then restart Explorer (or sign out and back in) so the shell extension reloads.
What to check afterwards: a file you edit under D:\work\monorepo\src should show the modified overlay, the same file under an excluded tree should show none, and right-click latency in the excluded folders should be noticeably lower. TGitCache.exe should still appear in Task Manager — if it does not, the cache is disabled and overlays will not refresh on their own.
Trade-offs and where this stops helping
- You lose at-a-glance status inside excluded trees. That is the point, but it means a stray edit under
node_moduleswill not be flagged. Usegit statusin Git Bash when you need the complete picture. - The lists are per-user, so on a shared machine each developer configures their own.
- On Windows 11, third-party shell extensions sit under Show more options (or Shift+F10) rather than the top-level context menu. That is a shell policy, not a TortoiseGit setting, and reinstalling will not move it.
- Complex history rewriting — long interactive rebases,
filter-repo,filter-branch— remains easier in the CLI. The Log dialog is good for reading history, cherry-picking and merging; it is not a full replacement for the command line. - If Explorer is unstable rather than merely slow, suspect a mismatched or duplicated shell extension (multiple TortoiseGit or TortoiseSVN versions, or a stale DLL left by an upgrade) before tuning paths.
Verification and rollback
To verify, restart Explorer, then open one folder inside an included path and one inside an excluded path and compare overlay behaviour. Confirm TGitCache.exe is running and compare right-click responsiveness in each folder.
To roll back, clear both the include and exclude lists in the same dialog and restart Explorer. Nothing outside TortoiseGit's per-user settings was modified. If you also changed the status cache mode, set it back to Default.
0 replies
A thoughtful contribution can make all the difference. Be the first to share one.