fix(utils): normalize MSYS/Cygwin Git paths on Windows

[adityasingh2400]

Pre-flight checklist

• I have read the Contributing Guidelines on pull requests.
• If this is a code change: I have written unit tests and/or added dogfooding pages to fully verify the new behavior.
• If this is a new API or substantial change: the PR has an accompanying issue (closes #0000) and the maintainers have approved on my working plan.

Motivation

Addresses #11920.

On Windows, when Git is invoked from a Unix-like shell (Git Bash, MSYS2, Cygwin), git rev-parse --show-toplevel can return a Unix-style absolute path that uses a drive mount prefix, e.g. /p/projets/my-repo instead of the native P:\projets\my-repo.

The eager Git VCS strategy added in 3.10 feeds that raw output into fs.realpath. Because /p/... is not a valid Windows path, fs.realpath/path.resolve resolves it against the root of the current drive, which duplicates the drive letter: /p/projets/my-repo becomes P:\p\projets\my-repo. The build then fails with:

ENOENT: no such file or directory, realpath 'P:\p\projets\my-repo'

CI did not catch this because the Git builds used on CI emit native Windows paths rather than MSYS mount-style paths, so the bad code path is only reached in those shells.

The fix

A small helper fromGitPathToNativePath() in pathUtils.ts converts a /<drive>/... mount path back to a native Windows path (/p/projets -> P:\projets). It is applied to the output of getGitRepoRoot and getGitSuperProjectRoot before fs.realpath is called.

The helper is deliberately conservative:

• It is a no-op on non-Windows platforms, where /c/... is a legitimate absolute path.
• It only rewrites a single-letter top-level segment (/c/, /p/, ...), which under MSYS/Cygwin is always a drive mount. Real posix paths like /home/... or /usr/... are left untouched.
• Native Windows paths (C:\..., C:/...) and UNC paths (//server/share) are returned unchanged.

Test Plan

Added unit tests in pathUtils.test.ts covering the conversion, the pass-through cases (native Windows, UNC, posix), and the non-Windows no-op, using the same process.platform override pattern already used in that file.

yarn vitest run packages/docusaurus-utils/src/__tests__/pathUtils.test.ts
# 14 passed

gitUtils.test.ts continues to pass (it exercises getGitRepoRoot/getGitSuperProjectRoot, which now route through the helper; on non-Windows the helper is a no-op so behavior is unchanged).

I do not have a Windows + Git Bash setup to reproduce the original ENOENT end to end, so I would appreciate confirmation from someone on the affected configuration that the build now succeeds with the default gitEagerVcs strategy. The unit tests assert that the exact /p/projets/my-repo -> P:\projets\my-repo conversion from the issue is correct.

Related issues/PRs

• Fixes the failure reported in 🐛 Windows: incorrect path conversion from Git POSIX paths (/x/...) to Windows paths (X:\...) #11920
• The eager Git VCS strategy was introduced in fix(utils): Git Eager VSC should have better DX #11804

[netlify]

✅ [V2]

Built without sensitive environment variables

Name	Link
🔨 Latest commit	3837b13
🔍 Latest deploy log	https://app.netlify.com/projects/docusaurus-2/deploys/6a12e9ceb56976000818b68f
😎 Deploy Preview	https://deploy-preview-12067--docusaurus-2.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.