Re: [PATCH 1/1] mingw: work around t2300's assuming non-Windows paths

Johannes Schindelin [off-list ref] writes:

On Windows, we have to juggle two different schemes of representing
paths: the native, Windows paths (the only ones known to the main
Git executable) on the one hand, and POSIX-ish ones used by the Bash
through MSYS2's POSIX emulation layer on the other hand.

A Windows path looks like this: C:\git-sdk-64\usr\src\git. In modern
Windows, it is almost always legal to use forward slashes as directory
separators, which is the reason why the Git executable itself would use
the path C:/git-sdk-64/usr/src/git instead. The equivalent POSIX-ish
path would be: /c/git-sdk-64/usr/src/git.

This patch works around the assumption of t2300-cd-to-toplevel.sh that
`git --exec-path` spits out a POSIX-ish path, by converting the output
accordingly.

Hmm, I am confused.  `git --exec-path` _is_ meant to "spit out" a
path that is usable when prepended/appended to $PATH [1], and it
does _not_ have to be POSIX-ish path.  It is totally up to the port
to adjust it to the platform's convention how the $PATH environment
variable is understood.

If $PATH cannot take C:/git-sdk-64/usr/src/git but does understand
/c/git-sdk-64/usr/src/git, perhaps "git --exec-path" should be
emitting the latter in the first place?


[Footnote]

*1* That after all was how we handled the painful 1.6 "'git-cmd' to
'git cmd'" transition (cf. $gmane/93793).

Hi Junio,

On Mon, 20 Jun 2016, Junio C Hamano wrote:

Johannes Schindelin [off-list ref] writes:

quoted

On Windows, we have to juggle two different schemes of representing
paths: the native, Windows paths (the only ones known to the main Git
executable) on the one hand, and POSIX-ish ones used by the Bash
through MSYS2's POSIX emulation layer on the other hand.

A Windows path looks like this: C:\git-sdk-64\usr\src\git. In modern
Windows, it is almost always legal to use forward slashes as directory
separators, which is the reason why the Git executable itself would
use the path C:/git-sdk-64/usr/src/git instead. The equivalent
POSIX-ish path would be: /c/git-sdk-64/usr/src/git.

This patch works around the assumption of t2300-cd-to-toplevel.sh that
`git --exec-path` spits out a POSIX-ish path, by converting the output
accordingly.

Hmm, I am confused.  `git --exec-path` _is_ meant to "spit out" a
path that is usable when prepended/appended to $PATH [1], and it
does _not_ have to be POSIX-ish path.  It is totally up to the port
to adjust it to the platform's convention how the $PATH environment
variable is understood.

The port does exactly what it is supposed to do: the output of `git
--exec-path` can be prepended/appended to %PATH%. The point here is:
%PATH% is *semicolon*-delimited.

All problems start when we do not use scripting native to Windows, but the
Bash. In the Bash, we *assume* that $PATH is *colon*-delimited. All the
time. And that is part of what makes a POSIX emulation layer on Windows so
challenging.

If $PATH cannot take C:/git-sdk-64/usr/src/git but does understand
/c/git-sdk-64/usr/src/git, perhaps "git --exec-path" should be
emitting the latter in the first place?

Again, %PATH% can take C:/... just fine. But the Bash gets the
POSIX-layer-munged $PATH which has POSIX-ish paths so that it can
colon-delimit its PATH and all shell scripts can continue to work.

So the root cause for the problem which requires this work-around is that
our test suite is written in shell script, which is inherently not as
portable as we think it is.

Does that address your puzzlement? If so, would you kindly advise how to
improve the commit message (or the patch)?

Ciao,
Dscho