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

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 21, 2016, 17:27 UTC
Message-ID: <xmqqk2hiqwpb.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <xmqqr3bqqxhc.fsf@gitster.mtv.corp.google.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 6 quoted lines

> I think you would need something similar to "pwd -W", that is, leave
> "git --exec-path" as a way to give shell scripts people have written
> over the years that allows them to say "git-cmd" as long as they do
> PATH="$(git --exec-path):$PATH" upfront.  And for Windows scripts,
> introduce a new option "git --exec-path-windows" that can give
> C:/git-sdk-64/usr/src/git (or even using backslash).

Of course we could go the other way. We can declare that the output of "git --exec-path" is the format that is platform-native pathname to the directory [*1*], introduce a new option that is better named than "--exec-path-to-include-in-PATH-in-shell-scripts" that does the "convert C:/ to /c/ on Windows before showing" thing, and rewrite all the references that does PATH=$(git --exec-path):$PATH in scripts to use that new option.

The fact remains that on some platforms two variants are needed. We can update our test scripts with "convert C:/ to /c/ on Windows" to work around a test failure like the patch under discussion did, but that approach would not scale to fix real world scripts that people already have, which is what I am trying to see if we can address in these two messages.

[Footnote]

*1* ...instead of "it is suitable for PATH=$(git --exec-path):$PATH in your shell scripts", which was the definition I used in the message I am responding to. "The name '--exec-path' implies it is a path to the directory, and it is more natural for that to be platform native" is a valid argument (and that is why I am saying "we could go the other way" here), but I am not convinced that the conclusion that the argument leads to is a better one in the practical sense.