Fix Source Control view dropping files with long paths on Windows

[yogeshwaran-c]

What / Why

On Windows, git status and git diff silently omit files whose absolute path exceeds MAX_PATH (260 characters) unless the core.longpaths config is enabled. Because the git extension does not opt in, those files are missing from the Source Control view and from commit comparison views, even though running git diff in a terminal (with the option enabled globally) lists them.

This is a frequent pain point for Windows users with deeply-nested workspaces — see #240770.

Fixes #240770

Fix

Inject -c core.longpaths=true into every git invocation made by the extension on Windows, via a small helper that runs inside Git.spawn:

• Windows-only — no-op on macOS and Linux, where the limit does not apply.
• Idempotent — skipped if the caller already supplied an explicit core.longpaths override (so per-command opt-outs still win).
• Non-invasive — does not modify the user's git configuration; the option is only set for the lifetime of the spawned process.

This keeps the extension's behavior consistent regardless of whether the user has core.longpaths set in their global git config, and matches what users expect after seeing the file in their terminal git status output.

Testing

• Verified manually on Windows 11 by creating a file inside a deeply nested directory whose absolute path exceeds 260 characters, modifying it, and confirming that:
  • Before the change, the file did not appear in the Source Control view, and the commit comparison view did not list it.
  • After the change, the file appears in the Changes group and in the commit's compare view, matching git diff behavior in the terminal.
• Existing short-path repositories continue to work unchanged.
• Verified the helper is a no-op when the call site already passes -c core.longpaths=....

[vs-code-engineering]

📬 CODENOTIFY

The following users are being notified based on files changed in this PR:

@lszomoru

Matched files:

• extensions/git/src/git.ts