{"thread":{"id":"42649","subject":"[PATCH 0/1] Fix testing of `master` on Windows","startedAt":"2016-06-18T10:49:13Z","lastAt":"2016-06-22T21:26:42Z","messageCount":11,"participants":["Johannes Schindelin","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":1},"messages":[{"id":"289569","messageId":"cover.1466246919.git.johannes.schindelin@gmx.de","threadId":"42649","inReplyTo":null,"subject":"[PATCH 0/1] Fix testing of `master` on Windows","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-06-18T10:49:03Z","receivedAt":"2016-06-18T10:49:13Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Sorry, I missed this (trivially-fixed) test breakage... FWIW this is\n*not* part of the rebase--helper patches ;-)\n\n\nJohannes Schindelin (1):\n mingw: work around t2300's assuming non-Windows paths\n\n t/t2300-cd-to-toplevel.sh | 10 +++++++++-\n 1 file changed, 9 insertions(+), 1 deletion(-)\n\nPublished-As: https://github.com/dscho/git/releases/tag/mingw-t2300-v1\n-- \n2.9.0.118.gce770ba.dirty\n\nbase-commit: 05219a1276341e72d8082d76b7f5ed394b7437a4\n"},{"id":"289570","messageId":"a8bebe126bcd047720a13e90b85b8dccb7231187.1466246919.git.johannes.schindelin@gmx.de","threadId":"42649","inReplyTo":"cover.1466246919.git.johannes.schindelin@gmx.de","subject":"[PATCH 1/1] mingw: work around t2300's assuming non-Windows paths","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-06-18T10:49:11Z","receivedAt":"2016-06-18T10:50:56Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"On Windows, we have to juggle two different schemes of representing\npaths: the native, Windows paths (the only ones known to the main\nGit executable) on the one hand, and POSIX-ish ones used by the Bash\nthrough MSYS2's POSIX emulation layer on the other hand.\n\nA Windows path looks like this: C:\\git-sdk-64\\usr\\src\\git. In modern\nWindows, it is almost always legal to use forward slashes as directory\nseparators, which is the reason why the Git executable itself would use\nthe path C:/git-sdk-64/usr/src/git instead. The equivalent POSIX-ish\npath would be: /c/git-sdk-64/usr/src/git.\n\nThis patch works around the assumption of t2300-cd-to-toplevel.sh that\n`git --exec-path` spits out a POSIX-ish path, by converting the output\naccordingly.\n\nSigned-off-by: Johannes Schindelin \n---\n t/t2300-cd-to-toplevel.sh | 10 +++++++++-\n 1 file changed, 9 insertions(+), 1 deletion(-)\n\ndiff --git a/t/t2300-cd-to-toplevel.sh b/t/t2300-cd-to-toplevel.sh\nindex cccd7d9..c8de6d8 100755\n--- a/t/t2300-cd-to-toplevel.sh\n+++ b/t/t2300-cd-to-toplevel.sh\n@@ -4,11 +4,19 @@ test_description='cd_to_toplevel'\n \n . ./test-lib.sh\n \n+EXEC_PATH=\"$(git --exec-path)\"\n+test_have_prereq !MINGW ||\n+case \"$EXEC_PATH\" in\n+[A-Za-z]:/*)\n+\tEXEC_PATH=\"/${EXEC_PATH%%:*}${EXEC_PATH#?:}\"\n+\t;;\n+esac\n+\n test_cd_to_toplevel () {\n \ttest_expect_success $3 \"$2\" '\n \t\t(\n \t\t\tcd '\"'$1'\"' &&\n-\t\t\tPATH=\"$(git --exec-path):$PATH\" &&\n+\t\t\tPATH=\"$EXEC_PATH:$PATH\" &&\n \t\t\t. git-sh-setup &&\n \t\t\tcd_to_toplevel &&\n \t\t\t[ \"$(pwd -P)\" = \"$TOPLEVEL\" ]\n-- \n2.9.0.118.gce770ba.dirty\n"},{"id":"289694","messageId":"xmqqmvmfu17f.fsf@gitster.mtv.corp.google.com","threadId":"42649","inReplyTo":"a8bebe126bcd047720a13e90b85b8dccb7231187.1466246919.git.johannes.schindelin@gmx.de","subject":"Re: [PATCH 1/1] mingw: work around t2300's assuming non-Windows paths","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-06-20T19:09:24Z","receivedAt":"2016-06-20T19:16:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Windows, we have to juggle two different schemes of representing\n> paths: the native, Windows paths (the only ones known to the main\n> Git executable) on the one hand, and POSIX-ish ones used by the Bash\n> through MSYS2's POSIX emulation layer on the other hand.\n>\n> A Windows path looks like this: C:\\git-sdk-64\\usr\\src\\git. In modern\n> Windows, it is almost always legal to use forward slashes as directory\n> separators, which is the reason why the Git executable itself would use\n> the path C:/git-sdk-64/usr/src/git instead. The equivalent POSIX-ish\n> path would be: /c/git-sdk-64/usr/src/git.\n>\n> This patch works around the assumption of t2300-cd-to-toplevel.sh that\n> `git --exec-path` spits out a POSIX-ish path, by converting the output\n> accordingly.\n\nHmm, I am confused. `git --exec-path` _is_ meant to \"spit out\" a\npath that is usable when prepended/appended to $PATH [1], and it\ndoes _not_ have to be POSIX-ish path. It is totally up to the port\nto adjust it to the platform's convention how the $PATH environment\nvariable is understood.\n\nIf $PATH cannot take C:/git-sdk-64/usr/src/git but does understand\n/c/git-sdk-64/usr/src/git, perhaps \"git --exec-path\" should be\nemitting the latter in the first place?\n\n\n[Footnote]\n\n*1* That after all was how we handled the painful 1.6 \"'git-cmd' to\n'git cmd'\" transition (cf. $gmane/93793).\n\n\n\n> Signed-off-by: Johannes Schindelin \n> ---\n> t/t2300-cd-to-toplevel.sh | 10 +++++++++-\n> 1 file changed, 9 insertions(+), 1 deletion(-)\n>\n> diff --git a/t/t2300-cd-to-toplevel.sh b/t/t2300-cd-to-toplevel.sh\n> index cccd7d9..c8de6d8 100755\n> --- a/t/t2300-cd-to-toplevel.sh\n> +++ b/t/t2300-cd-to-toplevel.sh\n> @@ -4,11 +4,19 @@ test_description='cd_to_toplevel'\n> \n> . ./test-lib.sh\n> \n> +EXEC_PATH=\"$(git --exec-path)\"\n> +test_have_prereq !MINGW ||\n> +case \"$EXEC_PATH\" in\n> +[A-Za-z]:/*)\n> +\tEXEC_PATH=\"/${EXEC_PATH%%:*}${EXEC_PATH#?:}\"\n> +\t;;\n> +esac\n> +\n> test_cd_to_toplevel () {\n> \ttest_expect_success $3 \"$2\" '\n> \t\t(\n> \t\t\tcd '\"'$1'\"' &&\n> -\t\t\tPATH=\"$(git --exec-path):$PATH\" &&\n> +\t\t\tPATH=\"$EXEC_PATH:$PATH\" &&\n> \t\t\t. git-sh-setup &&\n> \t\t\tcd_to_toplevel &&\n> \t\t\t[ \"$(pwd -P)\" = \"$TOPLEVEL\" ]\n"},{"id":"289761","messageId":"alpine.DEB.2.20.1606211356170.22630@virtualbox","threadId":"42649","inReplyTo":"xmqqmvmfu17f.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH 1/1] mingw: work around t2300's assuming non-Windows paths","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-06-21T12:01:31Z","receivedAt":"2016-06-21T12:01:59Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Mon, 20 Jun 2016, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > On Windows, we have to juggle two different schemes of representing\n> > paths: the native, Windows paths (the only ones known to the main Git\n> > executable) on the one hand, and POSIX-ish ones used by the Bash\n> > through MSYS2's POSIX emulation layer on the other hand.\n> >\n> > A Windows path looks like this: C:\\git-sdk-64\\usr\\src\\git. In modern\n> > Windows, it is almost always legal to use forward slashes as directory\n> > separators, which is the reason why the Git executable itself would\n> > use the path C:/git-sdk-64/usr/src/git instead. The equivalent\n> > POSIX-ish path would be: /c/git-sdk-64/usr/src/git.\n> >\n> > This patch works around the assumption of t2300-cd-to-toplevel.sh that\n> > `git --exec-path` spits out a POSIX-ish path, by converting the output\n> > accordingly.\n> \n> Hmm, I am confused. `git --exec-path` _is_ meant to \"spit out\" a\n> path that is usable when prepended/appended to $PATH [1], and it\n> does _not_ have to be POSIX-ish path. It is totally up to the port\n> to adjust it to the platform's convention how the $PATH environment\n> variable is understood.\n\nThe port does exactly what it is supposed to do: the output of `git\n--exec-path` can be prepended/appended to %PATH%. The point here is:\n%PATH% is *semicolon*-delimited.\n\nAll problems start when we do not use scripting native to Windows, but the\nBash. In the Bash, we *assume* that $PATH is *colon*-delimited. All the\ntime. And that is part of what makes a POSIX emulation layer on Windows so\nchallenging.\n\n> If $PATH cannot take C:/git-sdk-64/usr/src/git but does understand\n> /c/git-sdk-64/usr/src/git, perhaps \"git --exec-path\" should be\n> emitting the latter in the first place?\n\nAgain, %PATH% can take C:/... just fine. But the Bash gets the\nPOSIX-layer-munged $PATH which has POSIX-ish paths so that it can\ncolon-delimit its PATH and all shell scripts can continue to work.\n\nSo the root cause for the problem which requires this work-around is that\nour test suite is written in shell script, which is inherently not as\nportable as we think it is.\n\nDoes that address your puzzlement? If so, would you kindly advise how to\nimprove the commit message (or the patch)?\n\nCiao,\nDscho\n"},{"id":"289785","messageId":"xmqqr3bqqxhc.fsf@gitster.mtv.corp.google.com","threadId":"42649","inReplyTo":"alpine.DEB.2.20.1606211356170.22630@virtualbox","subject":"Re: [PATCH 1/1] mingw: work around t2300's assuming non-Windows paths","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-06-21T17:10:23Z","receivedAt":"2016-06-21T17:16:00Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n>> Hmm, I am confused. `git --exec-path` _is_ meant to \"spit out\" a\n>> path that is usable when prepended/appended to $PATH [1], and it\n>> does _not_ have to be POSIX-ish path. It is totally up to the port\n>> to adjust it to the platform's convention how the $PATH environment\n>> variable is understood.\n>\n> The port does exactly what it is supposed to do: the output of `git\n> --exec-path` can be prepended/appended to %PATH%. The point here is:\n> %PATH% is *semicolon*-delimited.\n\nI said $PATH because --exec-path does not care what you do with\n%PATH% but it deeply cares that its output is usable in $PATH.\n\nI think you would need something similar to \"pwd -W\", that is, leave\n\"git --exec-path\" as a way to give shell scripts people have written\nover the years that allows them to say \"git-cmd\" as long as they do\nPATH=\"$(git --exec-path):$PATH\" upfront. And for Windows scripts,\nintroduce a new option \"git --exec-path-windows\" that can give\nC:/git-sdk-64/usr/src/git (or even using backslash).\n\nI do not mean to say that exec_cmd.c::git_exec_path() function must\nreturn a string /c/git-sdk-64/usr/src/git by the above. It should\nkeep returning C:/git-sdk-64/usr/src/git, I think. Its use in\nexec_cmd.c::add_path() to use PATH_SEP to do the equivalent\ninternally for the platform would want C:/git-sdk-64/usr/src/git\nthere. Also I think exec_cmd.c::argv_exec_path should keep using\nplatform native format.\n\nPerhaps you can do the conversion you are doing with this\n\"let's change t2300\" patch instead in C where the return value of\ngit_exec_path() is fed to puts() in git.c::handle_options(), or\nbetter yet make a helper function git_exec_path_for_shell() that\ncalls git_exec_path() and does the conversion on Windows (and passes\nthe result from git_exec_path() intact on other platforms).\n\nI say all of the above because I see this in hits from \"git grep -e\n--exec-path\":\n\ncontrib/subtree/git-subtree.sh:PATH=$PATH:$(git --exec-path)\n\nand I would imagine there are countless other shell scripts that\nfollow the \"Output from 'git --exec-path' can be prepended/appended\nto PATH to allow you write 'git-cmd' instead of 'git cmd'\". They\nwould not work unless your \"git --exec-path\" gives an output that is\nusable by shell in $PATH (and not %PATH%).\n\n"},{"id":"289786","messageId":"xmqqk2hiqwpb.fsf@gitster.mtv.corp.google.com","threadId":"42649","inReplyTo":"xmqqr3bqqxhc.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH 1/1] mingw: work around t2300's assuming non-Windows paths","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-06-21T17:27:12Z","receivedAt":"2016-06-21T17:34:41Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> I think you would need something similar to \"pwd -W\", that is, leave\n> \"git --exec-path\" as a way to give shell scripts people have written\n> over the years that allows them to say \"git-cmd\" as long as they do\n> PATH=\"$(git --exec-path):$PATH\" upfront. And for Windows scripts,\n> introduce a new option \"git --exec-path-windows\" that can give\n> C:/git-sdk-64/usr/src/git (or even using backslash).\n\nOf course we could go the other way. We can declare that the output\nof \"git --exec-path\" is the format that is platform-native pathname\nto the directory [*1*], introduce a new option that is better\nnamed than \"--exec-path-to-include-in-PATH-in-shell-scripts\" that\ndoes the \"convert C:/ to /c/ on Windows before showing\" thing, and\nrewrite all the references that does PATH=$(git --exec-path):$PATH\nin scripts to use that new option.\n\nThe fact remains that on some platforms two variants are needed. We\ncan update our test scripts with \"convert C:/ to /c/ on Windows\" to\nwork around a test failure like the patch under discussion did, but\nthat approach would not scale to fix real world scripts that people\nalready have, which is what I am trying to see if we can address in\nthese two messages.\n\n\n[Footnote]\n\n*1* ...instead of \"it is suitable for PATH=$(git --exec-path):$PATH\nin your shell scripts\", which was the definition I used in the\nmessage I am responding to. \"The name '--exec-path' implies it is a\npath to the directory, and it is more natural for that to be platform\nnative\" is a valid argument (and that is why I am saying \"we could\ngo the other way\" here), but I am not convinced that the conclusion\nthat the argument leads to is a better one in the practical sense.\n"},{"id":"289833","messageId":"alpine.DEB.2.20.1606220927350.10382@virtualbox","threadId":"42649","inReplyTo":"xmqqk2hiqwpb.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH 1/1] mingw: work around t2300's assuming non-Windows paths","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-06-22T08:25:31Z","receivedAt":"2016-06-22T08:32:40Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Tue, 21 Jun 2016, Junio C Hamano wrote:\n\n> I said $PATH because --exec-path does not care what you do with\n> %PATH% but it deeply cares that its output is usable in $PATH.\n\nThe really, really, really important part to keep in mind is that there is\nno $PATH on Windows.\n\nSeriously, there is not.\n\nThere is a %PATH% because the scripting language native to Windows is the\nWindows batch language, which works with native Windows paths.\n\nThe same holds true for Git, BTW: all of the C code we have handles\nWindows paths just fine, as tedious as it is to keep this support intact.\n\nNow, all of the troubles enter with Git's relying on shell and Perl\nscripts. That is not a fault of the platform, of course, it is Git's\nfault. It is cute and convenient when your entire world is the Linux\ncommand-line, and when you do not really care about performance, either.\n\nAnd these shell scripts have a different idea about paths than Windows, or\neven the Git executable for that matter!\n\nNow, the big question is: how much do you want to cast this reliance on\nshell and Perl scripts in stone? That is an important question, and\naffects directly the answer to the related question: Should `git\n--exec-path` cater to POSIX shell scripts, or to scripts native to the\ncurrent platform?\n\nPersonally, I am not a fan of casting this in stone so much.\n\nYou see, shell scripts are as foreign to Windows as Windows batch scripts\nare to Linux. I doubt that you would accept any patch that would change\nall scripts to accept Windows-style paths even on Linux. Yet, the reverse\nis true: Git for Windows is expected to accept non-Windows paths.\n\nAnd all this talk did not even scratch the most important point. When I\nsay \"POSIX paths\" I know fully well that this is incorrect. POSIX paths\nare not required to use a forward slash as directory separator and a colon\nas path separator.\n\nThink VAX.\n\nI see the discussion veering into the wrong direction here. I am not\nprepared to accept the notion of shell scripting as portable, certainly\nnot when we rely on so many Unix-isms.\n\nSo unless we come up with a truly portable way to test Git, and to\nimplement scripted parts of Git, I am convinced that our best course of\naction is to continue to work around Git's erroneous assumption that shell\nscripting is as native to the current platform as the Git executable\nitself, and to continue to introduce glue code to keep things running\nrelatively smoothly.\n\nOf course, if you have a splendid idea how to fix the underlying issue, I\nam more than just eager to go there.\n\n> Junio C Hamano writes:\n> \n> > I think you would need something similar to \"pwd -W\", that is, leave\n> > \"git --exec-path\" as a way to give shell scripts people have written\n> > over the years that allows them to say \"git-cmd\" as long as they do\n> > PATH=\"$(git --exec-path):$PATH\" upfront. And for Windows scripts,\n> > introduce a new option \"git --exec-path-windows\" that can give\n> > C:/git-sdk-64/usr/src/git (or even using backslash).\n> \n> Of course we could go the other way. We can declare that the output\n> of \"git --exec-path\" is the format that is platform-native pathname\n> to the directory [*1*], introduce a new option that is better\n> named than \"--exec-path-to-include-in-PATH-in-shell-scripts\" that\n> does the \"convert C:/ to /c/ on Windows before showing\" thing, and\n> rewrite all the references that does PATH=$(git --exec-path):$PATH\n> in scripts to use that new option.\n\nI see your smirking when you wrote this.\n\n> The fact remains that on some platforms two variants are needed. We\n> can update our test scripts with \"convert C:/ to /c/ on Windows\" to\n> work around a test failure like the patch under discussion did, but\n> that approach would not scale to fix real world scripts that people\n> already have, which is what I am trying to see if we can address in\n> these two messages.\n\nThis overstates the importance of shell scripting in general Git usage,\nmethinks, and certainly the importance of --exec-path with regards to the\nPATH variable.\n\nGit's own shell scripts do not need to extend the PATH to include Git's\nexec path (when they are called, the PATH is already extended\nappropriately). And neither do other shell scripts: the dashed\ninvocations are deprecated for way too long a time already.\n\nPerformance characteristics as well as quite serious portability problems\n(just how much time do we still have to spend just to bend over backwards\nfor KSH, for example?) are simply not in favor of using shell scripting\nfor any serious Git operation.\n\nOf course, it is not as bad for Linux users because shell scripts have\ndecent performance characteristics there (at least if you work with\nprojects at most the size of the Linux kernel), and you always have\nat least a Dash, if not a Bash. But already going to MacOSX, shell scripts\nare not so much fun anymore.\n\n> *1* ...instead of \"it is suitable for PATH=$(git --exec-path):$PATH\n> in your shell scripts\", which was the definition I used in the\n> message I am responding to. \"The name '--exec-path' implies it is a\n> path to the directory, and it is more natural for that to be platform\n> native\" is a valid argument (and that is why I am saying \"we could\n> go the other way\" here), but I am not convinced that the conclusion\n> that the argument leads to is a better one in the practical sense.\n\nYes, the practical issue at hand is: we are pretty much stuck with shell\nscripting for Git's test suite (which is not nice for me: on the same\nmachine where the test suite requires an already painful 10 minutes to\ncomplete in a Linux VM, it requires 45 minutes to complete in the\nPOSIX-emulating Bash).\n\nAnd I would rather keep this test suite working on Windows using\nwork-arounds such as the patch in question than to spend a lot of effort\nto support portable scripting, when scripting does not really matter all\nthat much in practice to begin with.\n\nCiao,\nDscho\n"},{"id":"289864","messageId":"xmqqa8idnpj9.fsf@gitster.mtv.corp.google.com","threadId":"42649","inReplyTo":"alpine.DEB.2.20.1606220927350.10382@virtualbox","subject":"Re: [PATCH 1/1] mingw: work around t2300's assuming non-Windows paths","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-06-22T16:42:34Z","receivedAt":"2016-06-22T16:42:57Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Tue, 21 Jun 2016, Junio C Hamano wrote:\n>\n>> I said $PATH because --exec-path does not care what you do with\n>> %PATH% but it deeply cares that its output is usable in $PATH.\n>\n> The really, really, really important part to keep in mind is that there is\n> no $PATH on Windows.\n\nI think I know that well enough; please sanity check. My\nunderstanding is:\n\n * Your (emulated) getenv(3) reads %PATH% which may look like\n \"c:\\a\\b;c:\\c\\d\", i.e. Windows style.\n\n * Your argv_exec_path also looks like \"c:\\e\\f\", i.e. Windows\n style.\n\n * Your setup_path() would yield \"c:\\e\\f;c:\\a\\b;c:\\c\\d\" because it\n concatenates the above two with PATH_SEP, i.e. Windows style, and\n your setenv(3) will set that to %PATH%.\n\n * After all that happens, your run_command(), execv_git_cmd(),\n etc. would honor that %PATH%.\n\n * In all of the above, a back-slash can be (and may indeed be) a\n forward-slash, as library functions and system calls are prepared\n to take both since the good old DOS days. I.e. \"c:\\a\\b\" can be\n \"c:/a/b\". It cannot be \"/c/a/b\", however.\n\n * When bash gets spawned (perhaps because a hook is written in that\n language, perhaps because child_process.use_shell is set when\n executing an alias \"!cmd\", running a pager, or running an\n editor), the value of %PATH% derived by the above sequence is not\n exposed as $PATH. There is the \"rewrite leading C: with /C/\"\n outside us (i.e. in bash).\n\nAnd that is why I suggested to keep that \"internal paths are in\nplatform native format\" and apply the same conversion as what bash\ndoes immediately before the returned value from git_exec_path() is\nfed to puts(). That way, \"$PATH\" (not %PATH%) can be modified with\n\"$(git --exec-path)\" in scripts the same way on all the platforms\nand you do not have to break people's hooks.\n\nHaving said that, I realize that I missed one huge thing to take\ninto consideration. I assume that you have been shipping Git for\nWindows with this \"'git --exec-path' gives c:\\a\\b, not /c/a/b\"\nfeature for a long time, so existing Windows users will be broken if\nwe \"fix\" this (which would allow them to use shell scripts their\nfriends use on other platforms without modification). So from that\npoint alone, \"PATH=$(git --exec-path):$PATH in shell should work on\nany platform and \"git --exec-path\" should be fixed\" would not fly.\nThis simply is too late to fix.\n\nThe patch under discussion is the only door left for that test, and\na similar trickery is needed for any end-user scripts used for hooks\nand aliases that use 'git --exec-path', if they ever want to be\ncross-platform.\n\nSo let's take that \"if Windows do this\" change to t2300 as-is.\n"},{"id":"289897","messageId":"alpine.DEB.2.20.1606222103410.10382@virtualbox","threadId":"42649","inReplyTo":"xmqqa8idnpj9.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH 1/1] mingw: work around t2300's assuming non-Windows paths","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-06-22T20:06:08Z","receivedAt":"2016-06-22T20:06:30Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Wed, 22 Jun 2016, Junio C Hamano wrote:\n\n> So let's take that \"if Windows do this\" change to t2300 as-is.\n\nThanks!\nDscho\n"},{"id":"289898","messageId":"xmqqvb11kmog.fsf@gitster.mtv.corp.google.com","threadId":"42649","inReplyTo":"xmqqa8idnpj9.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH 1/1] mingw: work around t2300's assuming non-Windows paths","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-06-22T20:12:31Z","receivedAt":"2016-06-22T20:12:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> I think I know that well enough; please sanity check. My\n> understanding is:\n> ...\n> The patch under discussion is the only door left for that test, and\n> a similar trickery is needed for any end-user scripts used for hooks\n> and aliases that use 'git --exec-path', if they ever want to be\n> cross-platform.\n>\n> So let's take that \"if Windows do this\" change to t2300 as-is.\n\nAssuming that the sanity check passes, here is a suggested rewrite\nto explain the real problem better.\n\n-- >8 --\nFrom: Johannes Schindelin \nDate: Sat, 18 Jun 2016 12:49:11 +0200\nSubject: [PATCH] t2300: \"git --exec-path\" is not usable in $PATH on Windows as-is\n\nThe \"git\" command itself has an internal logic to prepend the\nexec-path to the PATH environment variable for processes it spawns.\nThat is how \". git-sh-setup\" in our scripted Porcelains can find the\ndot-sourced file in $GIT_EXEC_PATH that is not usually on user's\nPATH.\n\nWhen t2300 runs, because it is not spawned by the \"git\" command, the\nscriptlet being tested did not run with a realistic setting of PATH\nenvironment. It lacked the exec-path on the PATH, and failed to\nfind the dot-sourced file. A recent update to t2300 attempted to do\nso, with \"PATH=$(git --exec-path):$PATH\", which was the recommended\nway around v1.6.0 days (a script whose original was written before\nthat release that survives to this day is likely to have such a line).\n\nHowever, the \"git --exec-path\" command outputs C:\\path\\to\\exec\\dir\n(not /c/path/to/exec/dir) on Windows; the recent update failed to\nconsider the problem that comes from it.\n\nEven though Git itself, when doing the equivalent internally, does\nso in a platform native way (i.e. on Windows, C:\\path\\to\\exec\\dir is\nprepended to the existing value of %PATH% using ';' as a component\nseparator), the result is further massaged by bash and gets turned\ninto $PATH that uses /c/path/to/exec/dir with ':' separating the\ncomponents, which is the form understood by bash, so scripted\nPorcelains finds commands from PATH correctly even on Windows.\n\nAn end user script written in shell, however, cannot prepend\n\"C:\\path\\to\\exec\\dir:\" to the existing value of $PATH and expect\nbash to magically turn it into the form it understands. In other\nwords, \"PATH=$(git --exec-path):$PATH\" does not work as an emulation\nof what \"Git\" internally does to the PATH on Windows.\n\nTo correctly emulate how exec-path is prepended to the PATH\nenvironment internally on Windows, we'd need to convert\nC:\\git-sdk-64\\usr\\src\\git to at least /c\\git-sdk-64\\usr\\src\\git\nourselves before prepending it to PATH.\n\nSigned-off-by: Johannes Schindelin \nSigned-off-by: Junio C Hamano \n---\n t/t2300-cd-to-toplevel.sh | 10 +++++++++-\n 1 file changed, 9 insertions(+), 1 deletion(-)\n\ndiff --git a/t/t2300-cd-to-toplevel.sh b/t/t2300-cd-to-toplevel.sh\nindex cccd7d9..c8de6d8 100755\n--- a/t/t2300-cd-to-toplevel.sh\n+++ b/t/t2300-cd-to-toplevel.sh\n@@ -4,11 +4,19 @@ test_description='cd_to_toplevel'\n \n . ./test-lib.sh\n \n+EXEC_PATH=\"$(git --exec-path)\"\n+test_have_prereq !MINGW ||\n+case \"$EXEC_PATH\" in\n+[A-Za-z]:/*)\n+\tEXEC_PATH=\"/${EXEC_PATH%%:*}${EXEC_PATH#?:}\"\n+\t;;\n+esac\n+\n test_cd_to_toplevel () {\n \ttest_expect_success $3 \"$2\" '\n \t\t(\n \t\t\tcd '\"'$1'\"' &&\n-\t\t\tPATH=\"$(git --exec-path):$PATH\" &&\n+\t\t\tPATH=\"$EXEC_PATH:$PATH\" &&\n \t\t\t. git-sh-setup &&\n \t\t\tcd_to_toplevel &&\n \t\t\t[ \"$(pwd -P)\" = \"$TOPLEVEL\" ]\n-- \n2.9.0-346-g30ec1fd\n\n"},{"id":"289929","messageId":"alpine.DEB.2.20.1606222325560.10382@virtualbox","threadId":"42649","inReplyTo":"xmqqvb11kmog.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH 1/1] mingw: work around t2300's assuming non-Windows paths","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-06-22T21:26:18Z","receivedAt":"2016-06-22T21:26:42Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Wed, 22 Jun 2016, Junio C Hamano wrote:\n\n> Junio C Hamano writes:\n> \n> > I think I know that well enough; please sanity check. My\n> > understanding is:\n> > ...\n> > The patch under discussion is the only door left for that test, and\n> > a similar trickery is needed for any end-user scripts used for hooks\n> > and aliases that use 'git --exec-path', if they ever want to be\n> > cross-platform.\n> >\n> > So let's take that \"if Windows do this\" change to t2300 as-is.\n> \n> Assuming that the sanity check passes, here is a suggested rewrite\n> to explain the real problem better.\n\nYes, the sanity check passes, and your commit message is much better than\nmine.\n\nThanks!\nDscho\n"}]}