TortoiseGit Status cache transition from Default to Shell: balancing overlay freshness against refresh noise on large repositories

Direct answer

Switch to Shell only on local fixed-drive repositories where stale overlays cause real mistakes — branch switches, external git commands, or generated files that Explorer misses. Stay on Default when the main pain is Explorer refresh churn; a manual F5 or opening the commit dialog is cheaper than continuous rescans. There is no repository-size threshold that makes Shell extended preferable to Shell; it adds overlay detail (untracked/ignored coverage), not performance. For mixed local/remote environments, drive type is the primary lever: enable overlays on local fixed disks, suppress them on network, UNC, removable, or slow media via TortoiseGit's drive-type and Exclude-path settings.

Likely explanation vs. confirmed facts

• Likely: Default relies on the shared Windows shell cache, so overlays lag until Explorer refreshes; Shell makes TortoiseGit compute status directly, improving freshness at the cost of more work. Exact timing, cost, and labels vary by Windows version and TortoiseGit build — confirm by observation in your environment.
• Confirmed: Windows limits total overlay handlers; other shell extensions can crowd out TortoiseGit regardless of cache mode. If overlays disappear after installing other extensions, fix handler registration/order before tuning Status cache.
• Confirmed: Exclude paths and drive-type exclusions hide overlays only; they do not change Git status in commit, diff, or log dialogs.
• Confirmed: Shell extended adds refresh noise on trees with many untracked/ignored files; do not enable it globally on large repos without testing.

Practical boundary for a worthwhile change

1. Identify repositories where stale overlays have caused a wrong action (e.g., committing to the wrong branch because the overlay didn't update).
2. For each such repo on a local fixed drive, set Status cache → Shell, restart Explorer, then stage/modify/commit a file and time the overlay change.
3. If the delay is acceptable and freshness improves, keep Shell for that repo (or globally if all local repos behave similarly).
4. If Explorer becomes sluggish or disk/network activity spikes, revert to Default and add the path to Exclude paths instead.

Drive types and Exclude paths: weighing local vs. remote

• Local fixed disks: Allow overlays (Default or Shell). Add Exclude paths for large generated subtrees (build output, node_modules, .venv) to cut noise without losing commit/diff visibility.
• Network/UNC/removable/slow media: Disable overlays via drive-type exclusions. Overlay computation over the network is unreliable and slow; developers still get full status in commit/diff dialogs.
• Mixed environment: Set global cache to Default, enable Shell only for specific local repos that need it, and exclude all remote mount points.

One missing detail that changes the recommendation

Do remote working trees need overlays at all, or only commit/diff visibility? If overlays are optional remotely, exclude those paths rather than changing the global cache.

Verification steps (run once per environment)

1. In a small local repo: set Shell, restart Explorer, stage/modify/commit a file; record overlay latency vs. Default.
2. On a large remote repo: watch Explorer responsiveness and disk/network activity; if churn appears, revert to Default or exclude the path.
3. Check registered overlay handlers and their order; restart Explorer before judging cache behavior.
4. Apply drive-type and Exclude-path settings for remote paths; verify local overlays remain and remote paths stay quiet.
5. Test Shell extended only on a repo where the extra overlay detail is needed; compare delay and Explorer cost against Shell before adopting.