TortoiseGit and Git for Windows: Global git.exe Path Limits with Multiple Distributions

Question

TortoiseGit acts as a Windows Explorer shell extension and GUI front end, delegating all repository operations to an external git.exe. On machines where Git for Windows coexists with other distributions such as MSYS2 or portable builds, the integration boundary becomes the global Git.exe path setting. Because TortoiseGit does not bundle Git, the installer and Settings dialog rely on registry entries written by the Git for Windows setup to auto-detect a supported binary. Unregistered distributions remain invisible to that detection, forcing a manual path that applies to every repository opened by that TortoiseGit installation.

The unresolved design tension is that a single TortoiseGit instance cannot bind different working copies to different Git toolchains. Changing the configured path affects all repositories simultaneously and may require an Explorer restart to take effect consistently. There is also ambiguity about precedence: if another Git appears earlier in PATH, or if Git for Windows is relocated, operations may fail with generic dialogs or path-translation errors rather than a clear mismatch message. TortoiseGit release notes describe supported Git version ranges, but the boundary is not enforced at runtime.

Given these constraints, what is the intended workflow for teams that need both a registered Git for Windows install and an unregistered portable or MSYS2 Git on the same workstation? Should the global path be treated as a machine-level invariant, or are there supported mechanisms to isolate toolchain selection per project? Where does the boundary between TortoiseGit's configured path and the system PATH environment variable become observable during repository operations?

Wasi · Answer

Intended workflow
Treat the global git.exe path as a machine‑level invariant that points to the registered Git for Windows installation. For repositories that need a different distribution (portable Git, MSYS2, or another build), set a per‑repository override in the working copy’s .tgitconfig file. TortoiseGit checks the override first, then the global registry value, and finally falls back to the first git.exe found in the system PATH.

Steps to configure

Install Git for Windows normally; note its install folder (e.g., C:\Program Files\Git\bin\git.exe).
Open TortoiseGit → Settings for any repository, go to Git → Git executable path, browse to the Git for Windows binary, leave Apply to all repositories checked, and click OK. This writes the global registry value HKCU\Software\TortoiseGit\GitPath.
For each repository that must use a portable or MSYS2 Git:

Open TortoiseGit → Settings for that repository.
Navigate to Git → Git executable path, browse to the portable git.exe (e.g., D:\PortableGit\bin\git.exe).
Uncheck Apply to all repositories so the value is stored only in the local .tgitconfig file.
Click OK.

Verify the override:

Run TortoiseGit → Show log (or any Git command) and look at the command line displayed in the progress dialog; it should show the full path to the portable git.exe.
Inspect the repository’s .tgitconfig file; it should contain a section like:
[TortoiseGit]
gitPath = D:\PortableGit\bin\git.exe

Optionally, rename the global registry value GitPath temporarily; the repository should still use the portable Git, while other repos fall back to PATH or fail if no Git is found.

Where the boundary is observable
The boundary between the configured path and the system PATH becomes visible when TortoiseGit launches the external git.exe. If a per‑repository gitPath is set, that exact binary is used regardless of PATH. If the setting is empty, TortoiseGit queries the environment variable PATH and executes the first matching git.exe it finds. Changing the global registry value requires a restart of Windows Explorer (or logoff/logon) for the shell extension to pick up the new path; per‑repo changes take effect immediately for that repository.

TortoiseGit and Git for Windows: Global git.exe Path Limits with Multiple Distributions

1 answer

Intended workflow

Steps to configure

Where the boundary is observable

Your perspective belongs here.

0 question comments