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

[Junio C Hamano <gitster@pobox.com>]

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

> 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.