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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jun 21, 2016, 12:01 UTC
Message-ID: <alpine.DEB.2.20.1606211356170.22630@virtualbox>
In-Reply-To: <xmqqmvmfu17f.fsf@gitster.mtv.corp.google.com>

Hi Junio,

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

Show 22 quoted lines

> Johannes Schindelin <johannes.schindelin@gmx.de> 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.

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