diff options
author | Johannes Schindelin <johannes.schindelin@gmx.de> | 2016-06-18 12:49:11 +0200 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2016-06-22 14:47:36 -0700 |
commit | 412b9a16a007df93adcc88c0963a31399013ea37 (patch) | |
tree | 41120ac4377ba2f0798f6bea05efce9af23062e2 /t/t2300-cd-to-toplevel.sh | |
parent | t2300: run git-sh-setup in an environment that better mimics the real life (diff) | |
download | tgif-412b9a16a007df93adcc88c0963a31399013ea37.tar.xz |
t2300: "git --exec-path" is not usable in $PATH on Windows as-is
The "git" command prepends the exec-path to the PATH environment
variable for processes it spawns. That is how ". git-sh-setup" in
our scripted Porcelains can find the dot-sourced file in the
exec-path location that is not usually on user's PATH.
When t2300 runs, because it is not spawned by the "git" command, the
scriptlet being tested did not run with a realistic setting of PATH
environment. It lacked the exec-path on the PATH, and failed to
find the dot-sourced file. A recent update to t2300 attempted to
fix this, with "PATH=$(git --exec-path):$PATH", which has been the
recommended way around v1.6.0 days (a script whose original was
written before that release that survives to this day is likely to
have such a line).
However, the "git --exec-path" command outputs C:\path\to\exec\dir
(not /c/path/to/exec/dir) on Windows; the recent update failed to
consider the problem that comes from it.
Even though Git itself, when doing the equivalent internally, does
so in a platform native way (i.e. on Windows, C:\path\to\exec\dir is
prepended to the existing value of %PATH% using ';' as a component
separator), the result is further massaged by bash and gets turned
into $PATH that uses /c/path/to/exec/dir with ':' separating the
components, which is the form understood by bash, so scripted
Porcelains find commands from PATH correctly.
An end user script written in shell, however, cannot prepend
"C:\path\to\exec\dir:" to the existing value of $PATH and expect
bash to magically turn it into the form it understands. In other
words, "PATH=$(git --exec-path):$PATH" does not work as an emulation
of what "Git" internally does to the PATH on Windows.
To correctly emulate how exec-path is prepended to the PATH
environment internally on Windows, we'd need to convert
C:\git-sdk-64\usr\src\git to at least /c\git-sdk-64\usr\src\git
ourselves before prepending it to PATH.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/t2300-cd-to-toplevel.sh')
-rwxr-xr-x | t/t2300-cd-to-toplevel.sh | 10 |
1 files changed, 9 insertions, 1 deletions
diff --git a/t/t2300-cd-to-toplevel.sh b/t/t2300-cd-to-toplevel.sh index cccd7d923a..c8de6d8a19 100755 --- a/t/t2300-cd-to-toplevel.sh +++ b/t/t2300-cd-to-toplevel.sh @@ -4,11 +4,19 @@ test_description='cd_to_toplevel' . ./test-lib.sh +EXEC_PATH="$(git --exec-path)" +test_have_prereq !MINGW || +case "$EXEC_PATH" in +[A-Za-z]:/*) + EXEC_PATH="/${EXEC_PATH%%:*}${EXEC_PATH#?:}" + ;; +esac + test_cd_to_toplevel () { test_expect_success $3 "$2" ' ( cd '"'$1'"' && - PATH="$(git --exec-path):$PATH" && + PATH="$EXEC_PATH:$PATH" && . git-sh-setup && cd_to_toplevel && [ "$(pwd -P)" = "$TOPLEVEL" ] |