Junio C Hamano <gitster@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html