Git: `isRepositoryHuge` flag set during transient clone/checkout permanently freezes stale git status with no recovery short of restart

Summary

When a git repository is re-cloned (or undergoes a large checkout) while a VS Code window is open on that workspace, VS Code's built-in git extension captures a transient, momentary state where all files appear as deleted (D). The git.statusLimit guard then permanently sets isRepositoryHuge = true, which freezes all subsequent git status refreshes — including manual "Refresh" from the Source Control panel — until VS Code is restarted.

Steps to Reproduce

1. Open a large git repository (e.g., 10,000+ tracked files) in VS Code
2. From the integrated terminal, delete the repo directory and re-clone it (e.g., rm -rf . && git clone <url> .)
3. Wait for the clone to complete
4. Observe the Source Control panel — many files show as D (deleted) even though they exist on disk
5. Click the "Refresh" button in Source Control — the stale D decorations persist
6. Only restarting VS Code (or reloading the window) clears the stale state

Expected Behavior

After the clone completes and files are present on disk, VS Code should re-run git status and clear the stale D decorations — either automatically (once the transient state resolves) or at minimum when the user manually clicks "Refresh" in the Source Control panel.

Actual Behavior

• During the clone, the file watcher fires and triggers git status -z
• At that instant, all tracked files are missing from the working tree → git reports them all as deleted
• git.statusLimit (default: 10,000) is hit, so only the first 10,000 entries are captured (early-alphabetical files like .config, Jenkinsfile, README, etc.)
• The didHitLimit flag sets isRepositoryHuge = true
• From that point on, all file-watch events and manual refresh attempts are short-circuited by the huge-repository guard
• Stale D state is frozen until the extension host restarts

Evidence from logs

The VS Code remote server log shows the file watcher shutting down during the re-clone:

[warning] [File Watcher (node.js)] Watcher shutdown because watched path got deleted
[warning] [File Watcher (node.js)] Watcher shutdown because watched path got deleted
[warning] [File Watcher (node.js)] Watcher shutdown because watched path got deleted

Root Cause

The isRepositoryHuge flag was designed to protect against repositories that persistently have an enormous number of changes (e.g., Linux kernel). However, it gets permanently set from a transient spike during clone/checkout — when the working tree is momentarily empty. Once set, there is no recovery path:

• ❌ Manual "Refresh" in Source Control → ignored (guard short-circuits)
• ❌ Subsequent file events → ignored
• ❌ Only a full window reload / extension host restart clears it

Suggested Fixes

Any of the following would resolve the issue:

1. Re-evaluate isRepositoryHuge: On the next git status call, if the result count is below the limit, reset isRepositoryHuge = false so automatic refresh resumes.
2. Allow manual "Refresh" to bypass the guard: The user explicitly clicking "Refresh" should always trigger a fresh git status, regardless of the huge-repo flag.
3. Detect transient clone state: If .git/index.lock exists or .git/ is rapidly changing, suppress git status until the operation settles — rather than capturing a snapshot of an incomplete working tree.
4. Increase default git.statusLimit or make the limit configurable per-repository.

Environment

• VS Code: 1.123.0 (commit 6a44c352bd24569c417e530095901b649960f9f8)
• OS: RHEL 8.10 (Remote - SSH)
• Git: 2.x (shallow clone, --depth 1)
• Repository size: ~15 GB, ~74,000 tracked files, 150+ submodules

Workaround

Restart VS Code or reload the window (Developer: Reload Window). Alternatively, increase git.statusLimit in settings:

"git.statusLimit": 100000

Or close VS Code before performing large re-clones and reopen after completion.