summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJohannes Schindelin <johannes.schindelin@gmx.de>2016-06-18 10:49:11 (GMT)
committerJunio C Hamano <gitster@pobox.com>2016-06-22 21:47:36 (GMT)
commit412b9a16a007df93adcc88c0963a31399013ea37 (patch)
tree41120ac4377ba2f0798f6bea05efce9af23062e2
parentfe17fc0006927246c5905ef9352e7e89a3c5814b (diff)
downloadgit-412b9a16a007df93adcc88c0963a31399013ea37.zip
git-412b9a16a007df93adcc88c0963a31399013ea37.tar.gz
git-412b9a16a007df93adcc88c0963a31399013ea37.tar.bz2
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>
-rwxr-xr-xt/t2300-cd-to-toplevel.sh10
1 files changed, 9 insertions, 1 deletions
diff --git a/t/t2300-cd-to-toplevel.sh b/t/t2300-cd-to-toplevel.sh
index cccd7d9..c8de6d8 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" ]