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

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?