]> git.ipfire.org Git - thirdparty/git.git/commit
var(win32): do report the GIT_SHELL_PATH that is actually used
authorJohannes Schindelin <johannes.schindelin@gmx.de>
Sat, 13 Jul 2024 21:08:24 +0000 (21:08 +0000)
committerJunio C Hamano <gitster@pobox.com>
Sat, 13 Jul 2024 23:23:37 +0000 (16:23 -0700)
commit9ed143ee33c03880f4e7fd1d41df7b1bf8b244da
treeec5e12bfe29ff8583a88a711bd681d3339207ce9
parent877da5e208dfd747750e16f34a0275f3e598d8d2
var(win32): do report the GIT_SHELL_PATH that is actually used

On Windows, Unix-like paths like `/bin/sh` make very little sense. In
the best case, they simply don't work, in the worst case they are
misinterpreted as absolute paths that are relative to the drive
associated with the current directory.

To that end, Git does not actually use the path `/bin/sh` that is
recorded e.g. when `run_command()` is called with a Unix shell
command-line. Instead, as of 776297548e (Do not use SHELL_PATH from
build system in prepare_shell_cmd on Windows, 2012-04-17), it
re-interprets `/bin/sh` as "look up `sh` on the `PATH` and use the
result instead".

This is the logic users expect to be followed when running `git var
GIT_SHELL_PATH`.

However, when 1e65721227 (var: add support for listing the shell,
2023-06-27) introduced support for `git var GIT_SHELL_PATH`, Windows was
not special-cased as above, which is why it outputs `/bin/sh` even
though that disagrees with what Git actually uses.

Let's fix this by using the exact same logic as `prepare_shell_cmd()`,
adjusting the Windows-specific `git var GIT_SHELL_PATH` test case to
verify that it actually finds a working executable.

Reported-by: Phillip Wood <phillip.wood123@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/var.c
t/t0007-git-var.sh