Are git subcommands overriding PATH variable?

[GlassGruber]

I made a simple script that use curl for a git subcommand, but discovered that the script is not using the version of curl (v8.4.0) I have installed on my machine but the one provided by the git for Windows distribution (curl v8.2.1). When I use curl normally from the shell the correct one installed is picked up as expected.

I didn't file an issue because maybe there is something I'm missing since I'm using the portable version.

I'm using Git for Windows PortableGit-2.42.0.2-64-bit.7z.exe with curl v8.2.1

For what I can tell the PATH is edited before the git subcommand execution, and the folders in git for windows mingw64 folder are inserted before my PATH.

By copying the following example code in a file named like git-curlpath and placing it in a folder inside your PATH, should reproduce my issue.

#!/bin/bash
echo "result of which:"
which curl
echo

echo "result of where:"
where curl
echo

echo "current PATH:"
echo $PATH

In my case this is the output (with minor redaction):

$ git curlpath
result of which:
/mingw64/bin/curl

result of where:
[PATH TO GIT FOR WINDOWS]\git-for-windows_2.42.0.2\mingw64\bin\curl.exe
[PATH TO INSTALLED CURL]\curl-8.4.0_3-win64-mingw\bin\curl.exe

current PATH:
/mingw64/libexec/git-core:/mingw64/bin:/usr/bin:[REST OF PATH]

Thank you.

[rimrul]

Yes. We need to do this to avoid picking up random incompatible unix-ish executables along the way (cygwin executables, MS curl, MS find, winavr, ...).

[GlassGruber]

I see, interesting and totally understandable. Are there workarounds or maybe a setting or variable to disable this behavior?

In my case the main issue is that for some reasons the current bundled curl is not working anymore with some of my scripts; I'm not sure but I see that compared to what can be downloaded currently from curl.se the Features comparison is missing HTTP2/3 and others but can't really tell if that is the culprit

from curl.se:

curl 8.4.0 (x86_64-w64-mingw32) libcurl/8.4.0 OpenSSL/3.1.3 (Schannel) zlib/1.3 brotli/1.1.0 zstd/1.5.5 WinIDN libssh2/1.11.0 nghttp2/1.57.0 ngtcp2/1.0.0 nghttp3/1.0.0
Release-Date: 2023-10-11
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp ws wss
Features: alt-svc AsynchDNS brotli HSTS HTTP2 HTTP3 HTTPS-proxy IDN IPv6 Kerberos Largefile libz MultiSSL NTLM SPNEGO SSL SSPI threadsafe UnixSockets zstd

bundled:

curl 8.2.1 (x86_64-w64-mingw32) libcurl/8.2.1 Schannel zlib/1.3 brotli/1.0.9 zstd/1.5.5 libidn2/2.3.4 libpsl/0.21.2 (+libidn2/2.3.3) libssh2/1.11.0
Release-Date: 2023-07-26
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli HSTS HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM PSL SPNEGO SSL SSPI threadsafe UnixSockets zstd

[dscho]

Are there workarounds or maybe a setting or variable to disable this behavior?

No. If you wanted this, you'd need to send that (non-Windows-specific) feature request to the Git mailing list. See https://git-scm.com/community for more details.

In my case the main issue is that for some reasons the current bundled curl is not working anymore with some of my scripts;

Without seeing some concrete log, it is virtually impossible to even make an educated guess as to the reasons.

[GlassGruber]

I see, thank you for your answer. In the meantime the quick and super dirty solution was to use a symlink to curl.exe in the git windows /usr/bin folder to the one I have installed and everything was back in business.