You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently Bash detection on Win32 assume bash.exe from Git installation is used. However there can be different layout, e.g. UCRT64 git.exe on a raw MSYS2 installation set up by pacman -S ucrt64/mingw-w64-ucrt-x86_64-git, which will lead git executable file found in /ucrt64/bin relative to the MSYS2 root directory. (It may worth noting MSYS2 also have package msys/git of MSys/Cygwin but some packages like git-lfs are only available for native Win32 variants.) In such cases shell.ts won't find the correct path of bash.exe.
Moreover, if bash.exe is in the path, it should be used. The bash.exe for WSL is in a well-known location so it should be easy to exclude. It can be also detected by check the output of bash --version, the WSL one will have x86_64-pc-linux-gnu but no MSYS/Cygwin Bash should have linux-gnu in the target.
If your issue is distinct from these (e.g. specifically about MSYS2 non-standard layouts or WSL bash exclusion), please clarify the difference so maintainers can track it separately.
If your issue is distinct from these (e.g. specifically about MSYS2 non-standard layouts or WSL bash exclusion), please clarify the difference so maintainers can track it separately.
The point is that GNU Bash is independent to Git. Even if Git on Windows has bundled Bash because it depends on (both for development and for deployment) MSys (and now MSYS2) shell components including bash, it should not be assumed as the only way. And since all current Git for Windows packages are based on MSYS2 and few people build upstream Git in other way, it is easy to learn that MSYS2 is actually a more popular way to get a working bash on Windows.
It is also not that simple to say "non-standard", although some of the alternatives are considered unsupported by the official Git for Windows project. However, it is outdated in the sense of availability, becuase now the MSYS2 official packages have native Win32 packages without the need to edit /etc/pacman.conf : just to use the upstream MSYS2 instead.
if the bash.exe isn't in PATH how should we find it?
There's some git bash improvements I want to do, but additionally we shouldnt rely on bash as much.
Activity
github-actions commentedon Apr 11, 2026
This issue might be a duplicate of existing issues. Please check:
bash.exepath not found error on Windows (similar symptom of bash not being found/used)If your issue is distinct from these (e.g. specifically about MSYS2 non-standard layouts or WSL bash exclusion), please clarify the difference so maintainers can track it separately.
FrankHB commentedon Apr 11, 2026
The point is that GNU Bash is independent to Git. Even if Git on Windows has bundled Bash because it depends on (both for development and for deployment) MSys (and now MSYS2) shell components including
bash, it should not be assumed as the only way. And since all current Git for Windows packages are based on MSYS2 and few people build upstream Git in other way, it is easy to learn that MSYS2 is actually a more popular way to get a workingbashon Windows.It is also not that simple to say "non-standard", although some of the alternatives are considered unsupported by the official Git for Windows project. However, it is outdated in the sense of availability, becuase now the MSYS2 official packages have native Win32 packages without the need to edit
/etc/pacman.conf: just to use the upstream MSYS2 instead.See this Git for Windows document for some further clarification.
Hona commentedon Apr 12, 2026
if the bash.exe isn't in PATH how should we find it?
There's some git bash improvements I want to do, but additionally we shouldnt rely on bash as much.
For other bash executables we should support it
github-actions commentedon Jul 4, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.