"brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes: >> The "look on the %PATH%" strategy does not make any sense as an >> implementation for getting GIT_SHELL_PATH, which answers "what is >> the shell this instanciation of Git was built to work with?", at >> least to me. Maybe I am missing some knowledge on limitations on >> Windows and Git for Windows why it is done that way. > > Well, it may be that that's the approach that Git for Windows takes to > look up the shell. (I don't know for certain.) > If that _is_ what it does, then that's absolutely the value we > want because we want to use whatever shell Git for Windows uses. > I will say it's a risky approach because it could well also find a > Cygwin or MINGW shell (or, if it were called bash, WSL), but we > really want whatever Git for Windows does here. Yeah, absolutely it is risky unless it is doing the "we are relocatable, so where is the 'sh' _we_ installed?", which is what I would expect GIT_SHELL_PATH to be. > That's because external users who rely on Git for Windows to furnish a > POSIX shell will want to know the path, and this variable is the best > way to do that (and the reason I added it). If Git for Windows furnishes programs other than POSIX shell, paths to which external users would also want to learn, what happens? GIT_PERL_PATH, GIT_WISH_PATH, etc.? Locate them on PATH themselves shouldn't be rocket science (and instead of locating, just spawning them themselves would be even easier, I would presume). Thanks.
