Re: [PATCH 13/19] mingw: outsmart MSYS2's path substitution in t1508

On Sun, Jan 24, 2016 at 9:03 PM, Junio C Hamano [off-list ref] wrote:

Johannes Schindelin [off-list ref] writes:

quoted

A string of the form "@/abcd" is considered a file path
by the msys layer and therefore translated to a Windows path.

Here the trick is to double the slashes.

The MSYS2 patch translation can be studied by calling

      test-path-utils print_path <path>

This feels wrong.

The point of this test is that you can ask to checkout a branch
whose name is a strangely looking "@/at-test", and a ref whose name
is "refs/heads/@/at-test" indeed is created.

The current "checkout" may be lazy and not signal an error for a
branch name with two consecutive slashes, but I wouldn't be
surprised if we tighten that later, and more importantly, I do not
think we ever promised users if you asked a branch "a//b" to be
created, we would create "refs/heads/a/b".

The new test hardcodes and promises such an incompatible behaviour,
i.e. a request to create "@//b" results in "@/b" created, only to
users on MINGW, fracturing the expectations of the Git userbase.

What the commit message doesn't explain is that the MSYS2 Bash shell
automatically translates command-line arguments which look like
absolute POSIX paths into Windows paths on behalf of the program being
invoked. For instance, given the command-line:

    myprog /fish

the shell will translate /fish to a Windows pathname, such as C:\fish
before invoking myprog.exe. While this is often the desired behavior,
sometimes the argument represents something other than a path, and the
translation is unwanted. MSYS provides a way to suppress the behavior
manually by doubling the slash, so:

    myprog //fish

will invoke myprog.exe with literal argument /fish (notice the single slash).

This commit message is trying to say that MSYS shell undesirably sees
@/fish as an absolute path, thus tries translating it to a Windows
path, such as @C:\fish. The only way to suppress this unwanted
translation is to manually double the slash, hence the patch makes the
test use @//fish which, when finally seen by the program, is just
@/fish, as was intended in the first place. So, doubling the slash on
MINGW is not promising incompatible behavior for MINGW users; it's
just working around unwanted path translation of the shell.