{"thread":{"id":"44271","subject":"[PATCH 2/2] submodule: ignore trailing slash in relative url","startedAt":"2016-10-10T17:57:23Z","lastAt":"2016-10-18T20:06:16Z","messageCount":14,"participants":["Stefan Beller","Dennis Kaarsemaker","Johannes Schindelin","Junio C Hamano","Johannes Sixt"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"303769","messageId":"20161010175611.1058-2-sbeller@google.com","threadId":"44271","inReplyTo":"20161010175611.1058-1-sbeller@google.com","subject":"[PATCH 2/2] submodule: ignore trailing slash in relative url","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2016-10-10T17:56:11Z","receivedAt":"2016-10-10T17:57:23Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"This is similar to the previous patch, though no user reported a bug and\nI could not find a regressive behavior.\n\nHowever it is a good thing to be strict on the output and for that we\nalways omit a trailing slash.\n\nSigned-off-by: Stefan Beller <sbeller@google.com>\n---\n builtin/submodule--helper.c | 2 ++\n t/t0060-path-utils.sh       | 1 +\n 2 files changed, 3 insertions(+)\n\ndiff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c\nindex a7841a5..260f46f 100644\n--- a/builtin/submodule--helper.c\n+++ b/builtin/submodule--helper.c\n@@ -149,6 +149,8 @@ static char *relative_url(const char *remote_url,\n \t}\n \tstrbuf_reset(&sb);\n \tstrbuf_addf(&sb, \"%s%s%s\", remoteurl, colonsep ? \":\" : \"/\", url);\n+\tif (ends_with(url, \"/\"))\n+\t\tstrbuf_setlen(&sb, sb.len - 1);\n \tfree(remoteurl);\n \n \tif (starts_with_dot_slash(sb.buf))\ndiff --git a/t/t0060-path-utils.sh b/t/t0060-path-utils.sh\nindex 82b98f8..25b48e5 100755\n--- a/t/t0060-path-utils.sh\n+++ b/t/t0060-path-utils.sh\n@@ -319,6 +319,7 @@ test_submodule_relative_url \"../\" \"foo/bar\" \"../submodule\" \"../foo/submodule\"\n test_submodule_relative_url \"../\" \"foo\" \"../submodule\" \"../submodule\"\n \n test_submodule_relative_url \"(null)\" \"../foo/bar\" \"../sub/a/b/c\" \"../foo/sub/a/b/c\"\n+test_submodule_relative_url \"(null)\" \"../foo/bar\" \"../sub/a/b/c/\" \"../foo/sub/a/b/c\"\n test_submodule_relative_url \"(null)\" \"../foo/bar/\" \"../sub/a/b/c\" \"../foo/sub/a/b/c\"\n test_submodule_relative_url \"(null)\" \"../foo/bar\" \"../submodule\" \"../foo/submodule\"\n test_submodule_relative_url \"(null)\" \"../foo/submodule\" \"../submodule\" \"../foo/submodule\"\n-- \n2.10.1.382.ga23ca1b.dirty\n\n"},{"id":"303770","messageId":"20161010175611.1058-1-sbeller@google.com","threadId":"44271","inReplyTo":null,"subject":"[PATCH 1/2] submodule: ignore trailing slash on superproject URL","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2016-10-10T17:56:10Z","receivedAt":"2016-10-10T17:57:26Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"Before 63e95beb0 (2016-04-15, submodule: port resolve_relative_url from\nshell to C), it did not matter if the superprojects URL had a trailing\nslash or not. It was just chopped off as one of the first steps\n(The \"remoteurl=${remoteurl%/}\" near the beginning of\nresolve_relative_url(), which was removed in said commit).\n\nWhen porting this to the C version, an off-by-one error was introduced\nand we did not check the actual last character to be a slash, but the\nNULL delimiter.\n\nReintroduce the behavior from before 63e95beb0, to ignore the trailing\nslash.\n\nReported-by: <venv21@gmail.com>\nHelped-by: Dennis Kaarsemaker <dennis@kaarsemaker.net>\nSigned-off-by: Stefan Beller <sbeller@google.com>\n---\n builtin/submodule--helper.c | 6 ++++--\n t/t0060-path-utils.sh       | 1 +\n 2 files changed, 5 insertions(+), 2 deletions(-)\n\ndiff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c\nindex 444ec06..a7841a5 100644\n--- a/builtin/submodule--helper.c\n+++ b/builtin/submodule--helper.c\n@@ -95,6 +95,8 @@ static int chop_last_dir(char **remoteurl, int is_relative)\n  * NEEDSWORK: This works incorrectly on the domain and protocol part.\n  * remote_url      url              outcome          expectation\n  * http://a.com/b  ../c             http://a.com/c   as is\n+ * http://a.com/b/ ../c             http://a.com/c   same as previous line, but\n+ *                                                   ignore trailing slash in url\n  * http://a.com/b  ../../c          http://c         error out\n  * http://a.com/b  ../../../c       http:/c          error out\n  * http://a.com/b  ../../../../c    http:c           error out\n@@ -113,8 +115,8 @@ static char *relative_url(const char *remote_url,\n \tstruct strbuf sb = STRBUF_INIT;\n \tsize_t len = strlen(remoteurl);\n \n-\tif (is_dir_sep(remoteurl[len]))\n-\t\tremoteurl[len] = '\\0';\n+\tif (is_dir_sep(remoteurl[len-1]))\n+\t\tremoteurl[len-1] = '\\0';\n \n \tif (!url_is_local_not_ssh(remoteurl) || is_absolute_path(remoteurl))\n \t\tis_relative = 0;\ndiff --git a/t/t0060-path-utils.sh b/t/t0060-path-utils.sh\nindex bf2deee..82b98f8 100755\n--- a/t/t0060-path-utils.sh\n+++ b/t/t0060-path-utils.sh\n@@ -319,6 +319,7 @@ test_submodule_relative_url \"../\" \"foo/bar\" \"../submodule\" \"../foo/submodule\"\n test_submodule_relative_url \"../\" \"foo\" \"../submodule\" \"../submodule\"\n \n test_submodule_relative_url \"(null)\" \"../foo/bar\" \"../sub/a/b/c\" \"../foo/sub/a/b/c\"\n+test_submodule_relative_url \"(null)\" \"../foo/bar/\" \"../sub/a/b/c\" \"../foo/sub/a/b/c\"\n test_submodule_relative_url \"(null)\" \"../foo/bar\" \"../submodule\" \"../foo/submodule\"\n test_submodule_relative_url \"(null)\" \"../foo/submodule\" \"../submodule\" \"../foo/submodule\"\n test_submodule_relative_url \"(null)\" \"../foo\" \"../submodule\" \"../submodule\"\n-- \n2.10.1.382.ga23ca1b.dirty\n\n"},{"id":"303795","messageId":"1476129516.7457.6.camel@kaarsemaker.net","threadId":"44271","inReplyTo":"20161010175611.1058-1-sbeller@google.com","subject":"Re: [PATCH 1/2] submodule: ignore trailing slash on superproject URL","fromName":"Dennis Kaarsemaker","fromEmail":"dennis@kaarsemaker.net","sentAt":"2016-10-10T19:58:36Z","receivedAt":"2016-10-10T19:58:45Z","isPatch":true,"sender":{"key":"dennis@kaarsemaker.net","avatar":"https://avatars.githubusercontent.com/u/200649?v=4"},"body":"[And now with CC to the list, sorry Stefan]\n\nOn Mon, 2016-10-10 at 10:56 -0700, Stefan Beller wrote:\n> Before 63e95beb0 (2016-04-15, submodule: port resolve_relative_url from\n> shell to C), it did not matter if the superprojects URL had a trailing\n> slash or not. It was just chopped off as one of the first steps\n> (The \"remoteurl=${remoteurl%/}\" near the beginning of\n> resolve_relative_url(), which was removed in said commit).\n> \n> When porting this to the C version, an off-by-one error was introduced\n> and we did not check the actual last character to be a slash, but the\n> NULL delimiter.\n> \n> Reintroduce the behavior from before 63e95beb0, to ignore the trailing\n> slash.\n\nLooks good to me, and fixes my simple testcase and cloning epiphany\nwith trailing slash. Thanks!\n\nD.\n"},{"id":"303993","messageId":"alpine.DEB.2.20.1610121501390.3492@virtualbox","threadId":"44271","inReplyTo":"20161010175611.1058-1-sbeller@google.com","subject":"Re: [PATCH 1/2] submodule: ignore trailing slash on superproject URL","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-10-12T13:30:49Z","receivedAt":"2016-10-12T14:23:40Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Stefan,\n\nOn Mon, 10 Oct 2016, Stefan Beller wrote:\n\n> Before 63e95beb0 (2016-04-15, submodule: port resolve_relative_url from\n> shell to C), it did not matter if the superprojects URL had a trailing\n> slash or not. It was just chopped off as one of the first steps\n> (The \"remoteurl=${remoteurl%/}\" near the beginning of\n> resolve_relative_url(), which was removed in said commit).\n> \n> When porting this to the C version, an off-by-one error was introduced\n> and we did not check the actual last character to be a slash, but the\n> NULL delimiter.\n\nIt is a NUL delimiter, not a NULL delimiter.\n\n> diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c\n> index 444ec06..a7841a5 100644\n> --- a/builtin/submodule--helper.c\n> +++ b/builtin/submodule--helper.c\n> @@ -95,6 +95,8 @@ static int chop_last_dir(char **remoteurl, int is_relative)\n>   * NEEDSWORK: This works incorrectly on the domain and protocol part.\n>   * remote_url      url              outcome          expectation\n>   * http://a.com/b  ../c             http://a.com/c   as is\n> + * http://a.com/b/ ../c             http://a.com/c   same as previous line, but\n> + *                                                   ignore trailing slash in url\n>   * http://a.com/b  ../../c          http://c         error out\n>   * http://a.com/b  ../../../c       http:/c          error out\n>   * http://a.com/b  ../../../../c    http:c           error out\n> @@ -113,8 +115,8 @@ static char *relative_url(const char *remote_url,\n>  \tstruct strbuf sb = STRBUF_INIT;\n>  \tsize_t len = strlen(remoteurl);\n>  \n> -\tif (is_dir_sep(remoteurl[len]))\n> -\t\tremoteurl[len] = '\\0';\n> +\tif (is_dir_sep(remoteurl[len-1]))\n> +\t\tremoteurl[len-1] = '\\0';\n>  \n>  \tif (!url_is_local_not_ssh(remoteurl) || is_absolute_path(remoteurl))\n>  \t\tis_relative = 0;\n> diff --git a/t/t0060-path-utils.sh b/t/t0060-path-utils.sh\n> index bf2deee..82b98f8 100755\n> --- a/t/t0060-path-utils.sh\n> +++ b/t/t0060-path-utils.sh\n> @@ -319,6 +319,7 @@ test_submodule_relative_url \"../\" \"foo/bar\" \"../submodule\" \"../foo/submodule\"\n>  test_submodule_relative_url \"../\" \"foo\" \"../submodule\" \"../submodule\"\n>  \n>  test_submodule_relative_url \"(null)\" \"../foo/bar\" \"../sub/a/b/c\" \"../foo/sub/a/b/c\"\n> +test_submodule_relative_url \"(null)\" \"../foo/bar/\" \"../sub/a/b/c\" \"../foo/sub/a/b/c\"\n>  test_submodule_relative_url \"(null)\" \"../foo/bar\" \"../submodule\" \"../foo/submodule\"\n>  test_submodule_relative_url \"(null)\" \"../foo/submodule\" \"../submodule\" \"../foo/submodule\"\n>  test_submodule_relative_url \"(null)\" \"../foo\" \"../submodule\" \"../submodule\"\n\nI see that this already made it to `next`. I saw that because it breaks\nthe build of Git for Windows (this was not noticed earlier because other\ncompile failures prevented the tests from running), as now the test cases\n173 and 177 of t0060 fail (*not* the newly introduced 163).\n\nHere is the output with -v -x:\n\n-- snip --\n[...]\nexpecting success:\n                actual=$(git submodule--helper resolve-relative-url-test '(null)' '/usr/src/git/wip/t/trash directory.t0060-path-utils/.' '../.') &&\n                test \"$actual\" = 'C:/git-sdk-64/usr/src/git/wip/t/trash directory.t0060-path-utils/.'\n\n+++ git submodule--helper resolve-relative-url-test '(null)' '/usr/src/git/wip/t/trash directory.t0060-path-utils/.' ../.\n++ actual=C:/git-sdk-64/usr/src/git/wip/t/.\n++ test C:/git-sdk-64/usr/src/git/wip/t/. = 'C:/git-sdk-64/usr/src/git/wip/t/trash directory.t0060-path-utils/.'\nerror: last command exited with $?=1\nnot ok 172 - test_submodule_relative_url: (null) /usr/src/git/wip/t/trash directory.t0060-path-utils/. ../. => C:/git-sdk-64/usr/src/git/wip/t/trash directory.t0060-path-utils/.\n#\n#                       actual=$(git submodule--helper\n#                       resolve-relative-url-test '(null)'\n#                       '/usr/src/git/wip/t/trash\n#                       directory.t0060-path-utils/.' '../.') &&\n#                       test \"$actual\" =\n#                       'C:/git-sdk-64/usr/src/git/wip/t/trash\n#                       directory.t0060-path-utils/.'\n#\n[...]\nexpecting success:\n                actual=$(git submodule--helper resolve-relative-url-test '(null)' '/usr/src/git/wip/t/trash directory.t0060-path-utils/.' '../submodule') &&\n                test \"$actual\" = 'C:/git-sdk-64/usr/src/git/wip/t/trash directory.t0060-path-utils/submodule'\n\n+++ git submodule--helper resolve-relative-url-test '(null)' '/usr/src/git/wip/t/trash directory.t0060-path-utils/.' ../submodule\n++ actual=C:/git-sdk-64/usr/src/git/wip/t/submodule\n++ test C:/git-sdk-64/usr/src/git/wip/t/submodule = 'C:/git-sdk-64/usr/src/git/wip/t/trash directory.t0060-path-utils/submodule'\nerror: last command exited with $?=1\nnot ok 176 - test_submodule_relative_url: (null) /usr/src/git/wip/t/trash directory.t0060-path-utils/. ../submodule => C:/git-sdk-64/usr/src/git/wip/t/trash directory.t0060-path-utils/submodule\n#\n#                       actual=$(git submodule--helper\n#                       resolve-relative-url-test '(null)'\n#                       '/usr/src/git/wip/t/trash\n#                       directory.t0060-path-utils/.' '../submodule') &&\n#                       test \"$actual\" =\n#                       'C:/git-sdk-64/usr/src/git/wip/t/trash\n#                       directory.t0060-path-utils/submodule'\n#\n[...]\n-- snap --\n\nFor comparison, this is how it succeeds in an Ubuntu VM:\n\n-- snap --\nexpecting success:\n                actual=$(git submodule--helper resolve-relative-url-test '(null)' '/home/virtualbox/git/wip/t/trash directory.t0060-path-utils/.' '../.') &&\n                test \"$actual\" = '/home/virtualbox/git/wip/t/trash directory.t0060-path-utils/.'\n\n+++ git submodule--helper resolve-relative-url-test '(null)' '/home/virtualbox/git/wip/t/trash directory.t0060-path-utils/.' ../.\n++ actual='/home/virtualbox/git/wip/t/trash directory.t0060-path-utils/.'\n++ test '/home/virtualbox/git/wip/t/trash directory.t0060-path-utils/.' = '/home/virtualbox/git/wip/t/trash directory.t0060-path-utils/.'\n+ test_eval_ret_=0\n+ want_trace\n+ test t = t\n+ test t = t\n+ set +x\nok 173 - test_submodule_relative_url: (null) /home/virtualbox/git/wip/t/trash directory.t0060-path-utils/. ../. => /home/virtualbox/git/wip/t/trash directory.t0060-path-utils/.\n-- snap --\n\nThe reason that this fails on Windows is that the POSIX->Windows path\nmangling of the MSYS2 shell strips the trailing . from \"/some/directory/.\"\nwhen converting it to \"C:/git-sdk-64/some/directory\", and for a good\nreason: most Windows programs do not handle the trailing \".\" very well.\n\nOne very, very ugly workaround for this newly-introduced breakage would be\nthis:\n\n-- snip --\ndiff --git a/t/t0060-path-utils.sh b/t/t0060-path-utils.sh\nindex 82b98f8..abd82e9 100755\n--- a/t/t0060-path-utils.sh\n+++ b/t/t0060-path-utils.sh\n@@ -328,11 +328,11 @@ test_submodule_relative_url \"(null)\" \"./foo\" \"../submodule\" \"submodule\"\n test_submodule_relative_url \"(null)\" \"//somewhere else/repo\" \"../subrepo\" \"//somewhere else/subrepo\"\n test_submodule_relative_url \"(null)\" \"$PWD/subsuper_update_r\" \"../subsubsuper_update_r\" \"$(pwd)/subsubsuper_update_r\"\n test_submodule_relative_url \"(null)\" \"$PWD/super_update_r2\" \"../subsuper_update_r\" \"$(pwd)/subsuper_update_r\"\n-test_submodule_relative_url \"(null)\" \"$PWD/.\" \"../.\" \"$(pwd)/.\"\n+test_submodule_relative_url \"(null)\" \"$(pwd)/.\" \"../.\" \"$(pwd)/.\"\n test_submodule_relative_url \"(null)\" \"$PWD\" \"./.\" \"$(pwd)/.\"\n test_submodule_relative_url \"(null)\" \"$PWD/addtest\" \"../repo\" \"$(pwd)/repo\"\n test_submodule_relative_url \"(null)\" \"$PWD\" \"./ \" \"$(pwd)/ \"\n-test_submodule_relative_url \"(null)\" \"$PWD/.\" \"../submodule\" \"$(pwd)/submodule\"\n+test_submodule_relative_url \"(null)\" \"$(pwd)/.\" \"../submodule\" \"$(pwd)/submodule\"\n test_submodule_relative_url \"(null)\" \"$PWD/submodule\" \"../submodule\" \"$(pwd)/submodule\"\n test_submodule_relative_url \"(null)\" \"$PWD/home2/../remote\" \"../bundle1\" \"$(pwd)/home2/../bundle1\"\n test_submodule_relative_url \"(null)\" \"$PWD/submodule_update_repo\" \"./.\" \"$(pwd)/submodule_update_repo/.\"\n-- snap --\n\nThe reasons this is ugly: we specifically test for *Unixy* paths when we\nuse $PWD, as opposed to *Windowsy* paths when using $(pwd). We do this to\nensure a certain level of confidence that running things such as\n\n\tgit clone --recurse-submodules /z/project/.\n\nwork. And now that does not work anymore.\n\nSo where to go from here?\n\nCiao,\nDscho\n"},{"id":"304013","messageId":"CAGZ79kYDpth7YDbN0VRD0dcpp7aeQ-y4HSEhsmd_c46ggZoXsg@mail.gmail.com","threadId":"44271","inReplyTo":"alpine.DEB.2.20.1610121501390.3492@virtualbox","subject":"Re: [PATCH 1/2] submodule: ignore trailing slash on superproject URL","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2016-10-12T17:06:22Z","receivedAt":"2016-10-12T17:13:19Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Wed, Oct 12, 2016 at 6:30 AM, Johannes Schindelin\n<Johannes.Schindelin@gmx.de> wrote:\n> Hi Stefan,\n>\n> On Mon, 10 Oct 2016, Stefan Beller wrote:\n>\n>> Before 63e95beb0 (2016-04-15, submodule: port resolve_relative_url from\n>> shell to C), it did not matter if the superprojects URL had a trailing\n>> slash or not. It was just chopped off as one of the first steps\n>> (The \"remoteurl=${remoteurl%/}\" near the beginning of\n>> resolve_relative_url(), which was removed in said commit).\n>>\n>> When porting this to the C version, an off-by-one error was introduced\n>> and we did not check the actual last character to be a slash, but the\n>> NULL delimiter.\n>\n> It is a NUL delimiter, not a NULL delimiter.\n\n null character ('\\0', called NUL in ASCII)\nI see. Thanks for pointing out.\n\n>\n>> diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c\n>> index 444ec06..a7841a5 100644\n>> --- a/builtin/submodule--helper.c\n>> +++ b/builtin/submodule--helper.c\n>> @@ -95,6 +95,8 @@ static int chop_last_dir(char **remoteurl, int is_relative)\n>>   * NEEDSWORK: This works incorrectly on the domain and protocol part.\n>>   * remote_url      url              outcome          expectation\n>>   * http://a.com/b  ../c             http://a.com/c   as is\n>> + * http://a.com/b/ ../c             http://a.com/c   same as previous line, but\n>> + *                                                   ignore trailing slash in url\n>>   * http://a.com/b  ../../c          http://c         error out\n>>   * http://a.com/b  ../../../c       http:/c          error out\n>>   * http://a.com/b  ../../../../c    http:c           error out\n>> @@ -113,8 +115,8 @@ static char *relative_url(const char *remote_url,\n>>       struct strbuf sb = STRBUF_INIT;\n>>       size_t len = strlen(remoteurl);\n>>\n>> -     if (is_dir_sep(remoteurl[len]))\n>> -             remoteurl[len] = '\\0';\n>> +     if (is_dir_sep(remoteurl[len-1]))\n>> +             remoteurl[len-1] = '\\0';\n>>\n>>       if (!url_is_local_not_ssh(remoteurl) || is_absolute_path(remoteurl))\n>>               is_relative = 0;\n>> diff --git a/t/t0060-path-utils.sh b/t/t0060-path-utils.sh\n>> index bf2deee..82b98f8 100755\n>> --- a/t/t0060-path-utils.sh\n>> +++ b/t/t0060-path-utils.sh\n>> @@ -319,6 +319,7 @@ test_submodule_relative_url \"../\" \"foo/bar\" \"../submodule\" \"../foo/submodule\"\n>>  test_submodule_relative_url \"../\" \"foo\" \"../submodule\" \"../submodule\"\n>>\n>>  test_submodule_relative_url \"(null)\" \"../foo/bar\" \"../sub/a/b/c\" \"../foo/sub/a/b/c\"\n>> +test_submodule_relative_url \"(null)\" \"../foo/bar/\" \"../sub/a/b/c\" \"../foo/sub/a/b/c\"\n>>  test_submodule_relative_url \"(null)\" \"../foo/bar\" \"../submodule\" \"../foo/submodule\"\n>>  test_submodule_relative_url \"(null)\" \"../foo/submodule\" \"../submodule\" \"../foo/submodule\"\n>>  test_submodule_relative_url \"(null)\" \"../foo\" \"../submodule\" \"../submodule\"\n>\n> I see that this already made it to `next`. I saw that because it breaks\n> the build of Git for Windows (this was not noticed earlier because other\n> compile failures prevented the tests from running), as now the test cases\n> 173 and 177 of t0060 fail (*not* the newly introduced 163).\n>\n> Here is the output with -v -x:\n>\n> -- snip --\n> [...]\n> expecting success:\n>                 actual=$(git submodule--helper resolve-relative-url-test '(null)' '/usr/src/git/wip/t/trash directory.t0060-path-utils/.' '../.') &&\n>                 test \"$actual\" = 'C:/git-sdk-64/usr/src/git/wip/t/trash directory.t0060-path-utils/.'\n>\n> +++ git submodule--helper resolve-relative-url-test '(null)' '/usr/src/git/wip/t/trash directory.t0060-path-utils/.' ../.\n> ++ actual=C:/git-sdk-64/usr/src/git/wip/t/.\n> ++ test C:/git-sdk-64/usr/src/git/wip/t/. = 'C:/git-sdk-64/usr/src/git/wip/t/trash directory.t0060-path-utils/.'\n\nSo this wipes away one dir too much in a test that doesn't end with a\ndir separator\n(In Windows that is '/' and '\\' only, no dots?)\n\n> error: last command exited with $?=1\n> not ok 172 - test_submodule_relative_url: (null) /usr/src/git/wip/t/trash directory.t0060-path-utils/. ../. => C:/git-sdk-64/usr/src/git/wip/t/trash directory.t0060-path-utils/.\n> #\n> #                       actual=$(git submodule--helper\n> #                       resolve-relative-url-test '(null)'\n> #                       '/usr/src/git/wip/t/trash\n> #                       directory.t0060-path-utils/.' '../.') &&\n> #                       test \"$actual\" =\n> #                       'C:/git-sdk-64/usr/src/git/wip/t/trash\n> #                       directory.t0060-path-utils/.'\n> #\n> [...]\n> expecting success:\n>                 actual=$(git submodule--helper resolve-relative-url-test '(null)' '/usr/src/git/wip/t/trash directory.t0060-path-utils/.' '../submodule') &&\n>                 test \"$actual\" = 'C:/git-sdk-64/usr/src/git/wip/t/trash directory.t0060-path-utils/submodule'\n>\n> +++ git submodule--helper resolve-relative-url-test '(null)' '/usr/src/git/wip/t/trash directory.t0060-path-utils/.' ../submodule\n> ++ actual=C:/git-sdk-64/usr/src/git/wip/t/submodule\n> ++ test C:/git-sdk-64/usr/src/git/wip/t/submodule = 'C:/git-sdk-64/usr/src/git/wip/t/trash directory.t0060-path-utils/submodule'\n> error: last command exited with $?=1\n> not ok 176 - test_submodule_relative_url: (null) /usr/src/git/wip/t/trash directory.t0060-path-utils/. ../submodule => C:/git-sdk-64/usr/src/git/wip/t/trash directory.t0060-path-utils/submodule\n> #\n> #                       actual=$(git submodule--helper\n> #                       resolve-relative-url-test '(null)'\n> #                       '/usr/src/git/wip/t/trash\n> #                       directory.t0060-path-utils/.' '../submodule') &&\n> #                       test \"$actual\" =\n> #                       'C:/git-sdk-64/usr/src/git/wip/t/trash\n> #                       directory.t0060-path-utils/submodule'\n> #\n> [...]\n> -- snap --\n>\n> For comparison, this is how it succeeds in an Ubuntu VM:\n>\n> -- snap --\n> expecting success:\n>                 actual=$(git submodule--helper resolve-relative-url-test '(null)' '/home/virtualbox/git/wip/t/trash directory.t0060-path-utils/.' '../.') &&\n>                 test \"$actual\" = '/home/virtualbox/git/wip/t/trash directory.t0060-path-utils/.'\n>\n> +++ git submodule--helper resolve-relative-url-test '(null)' '/home/virtualbox/git/wip/t/trash directory.t0060-path-utils/.' ../.\n> ++ actual='/home/virtualbox/git/wip/t/trash directory.t0060-path-utils/.'\n> ++ test '/home/virtualbox/git/wip/t/trash directory.t0060-path-utils/.' = '/home/virtualbox/git/wip/t/trash directory.t0060-path-utils/.'\n> + test_eval_ret_=0\n> + want_trace\n> + test t = t\n> + test t = t\n> + set +x\n> ok 173 - test_submodule_relative_url: (null) /home/virtualbox/git/wip/t/trash directory.t0060-path-utils/. ../. => /home/virtualbox/git/wip/t/trash directory.t0060-path-utils/.\n> -- snap --\n>\n> The reason that this fails on Windows is that the POSIX->Windows path\n> mangling of the MSYS2 shell strips the trailing . from \"/some/directory/.\"\n> when converting it to \"C:/git-sdk-64/some/directory\", and for a good\n> reason: most Windows programs do not handle the trailing \".\" very well.\n>\n> One very, very ugly workaround for this newly-introduced breakage would be\n> this:\n>\n> -- snip --\n> diff --git a/t/t0060-path-utils.sh b/t/t0060-path-utils.sh\n> index 82b98f8..abd82e9 100755\n> --- a/t/t0060-path-utils.sh\n> +++ b/t/t0060-path-utils.sh\n> @@ -328,11 +328,11 @@ test_submodule_relative_url \"(null)\" \"./foo\" \"../submodule\" \"submodule\"\n>  test_submodule_relative_url \"(null)\" \"//somewhere else/repo\" \"../subrepo\" \"//somewhere else/subrepo\"\n>  test_submodule_relative_url \"(null)\" \"$PWD/subsuper_update_r\" \"../subsubsuper_update_r\" \"$(pwd)/subsubsuper_update_r\"\n>  test_submodule_relative_url \"(null)\" \"$PWD/super_update_r2\" \"../subsuper_update_r\" \"$(pwd)/subsuper_update_r\"\n> -test_submodule_relative_url \"(null)\" \"$PWD/.\" \"../.\" \"$(pwd)/.\"\n> +test_submodule_relative_url \"(null)\" \"$(pwd)/.\" \"../.\" \"$(pwd)/.\"\n>  test_submodule_relative_url \"(null)\" \"$PWD\" \"./.\" \"$(pwd)/.\"\n>  test_submodule_relative_url \"(null)\" \"$PWD/addtest\" \"../repo\" \"$(pwd)/repo\"\n>  test_submodule_relative_url \"(null)\" \"$PWD\" \"./ \" \"$(pwd)/ \"\n> -test_submodule_relative_url \"(null)\" \"$PWD/.\" \"../submodule\" \"$(pwd)/submodule\"\n> +test_submodule_relative_url \"(null)\" \"$(pwd)/.\" \"../submodule\" \"$(pwd)/submodule\"\n>  test_submodule_relative_url \"(null)\" \"$PWD/submodule\" \"../submodule\" \"$(pwd)/submodule\"\n>  test_submodule_relative_url \"(null)\" \"$PWD/home2/../remote\" \"../bundle1\" \"$(pwd)/home2/../bundle1\"\n>  test_submodule_relative_url \"(null)\" \"$PWD/submodule_update_repo\" \"./.\" \"$(pwd)/submodule_update_repo/.\"\n> -- snap --\n>\n> The reasons this is ugly: we specifically test for *Unixy* paths when we\n> use $PWD, as opposed to *Windowsy* paths when using $(pwd). We do this to\n> ensure a certain level of confidence that running things such as\n>\n>         git clone --recurse-submodules /z/project/.\n>\n> work. And now that does not work anymore.\n\nAfter a while of thinking how I could fix it, it occurs to me, I could\nclaim the removal of the dot as a defect in the Windows path handling. ;)\nBut that doesn't help users.\n\nWould it be possible to mark the last dir separator special once the\ntrailing dot is removed? (i.e. put a \\ there, and in this patch we\nonly check for /)\nSounds hacky to me, though.\n\n>\n> So where to go from here?\n\nSo IIUC this patch fixed a bug in Git and introduced a very similar bug\nin Git for Windows?\n\nI have no expertise on how to deal with these path issues, but it sounds like\nthis dot-stripping is done too early, i.e. you'd want to first let the\nGit part handle\nthe URL concatenation and stuff and only at the end when it comes to using\nthe path it should get the Windows treatment?\n\nThanks,\nStefan\n\n>\n> Ciao,\n> Dscho\n"},{"id":"304073","messageId":"alpine.DEB.2.20.1610131255001.197091@virtualbox","threadId":"44271","inReplyTo":"CAGZ79kYDpth7YDbN0VRD0dcpp7aeQ-y4HSEhsmd_c46ggZoXsg@mail.gmail.com","subject":"Re: [PATCH 1/2] submodule: ignore trailing slash on superproject URL","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-10-13T11:11:51Z","receivedAt":"2016-10-13T11:13:48Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Stefan,\n\nOn Wed, 12 Oct 2016, Stefan Beller wrote:\n\n> On Wed, Oct 12, 2016 at 6:30 AM, Johannes Schindelin\n> <Johannes.Schindelin@gmx.de> wrote:\n> >\n> > On Mon, 10 Oct 2016, Stefan Beller wrote:\n> >\n> >> diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c\n> >> index 444ec06..a7841a5 100644\n> >> --- a/builtin/submodule--helper.c\n> >> +++ b/builtin/submodule--helper.c\n> >> @@ -95,6 +95,8 @@ static int chop_last_dir(char **remoteurl, int is_relative)\n> >>   * NEEDSWORK: This works incorrectly on the domain and protocol part.\n> >>   * remote_url      url              outcome          expectation\n> >>   * http://a.com/b  ../c             http://a.com/c   as is\n> >> + * http://a.com/b/ ../c             http://a.com/c   same as previous line, but\n> >> + *                                                   ignore trailing slash in url\n> >>   * http://a.com/b  ../../c          http://c         error out\n> >>   * http://a.com/b  ../../../c       http:/c          error out\n> >>   * http://a.com/b  ../../../../c    http:c           error out\n> >> @@ -113,8 +115,8 @@ static char *relative_url(const char *remote_url,\n> >>       struct strbuf sb = STRBUF_INIT;\n> >>       size_t len = strlen(remoteurl);\n> >>\n> >> -     if (is_dir_sep(remoteurl[len]))\n> >> -             remoteurl[len] = '\\0';\n> >> +     if (is_dir_sep(remoteurl[len-1]))\n> >> +             remoteurl[len-1] = '\\0';\n> >>\n> >>       if (!url_is_local_not_ssh(remoteurl) || is_absolute_path(remoteurl))\n> >>               is_relative = 0;\n> >> diff --git a/t/t0060-path-utils.sh b/t/t0060-path-utils.sh\n> >> index bf2deee..82b98f8 100755\n> >> --- a/t/t0060-path-utils.sh\n> >> +++ b/t/t0060-path-utils.sh\n> >> @@ -319,6 +319,7 @@ test_submodule_relative_url \"../\" \"foo/bar\" \"../submodule\" \"../foo/submodule\"\n> >>  test_submodule_relative_url \"../\" \"foo\" \"../submodule\" \"../submodule\"\n> >>\n> >>  test_submodule_relative_url \"(null)\" \"../foo/bar\" \"../sub/a/b/c\" \"../foo/sub/a/b/c\"\n> >> +test_submodule_relative_url \"(null)\" \"../foo/bar/\" \"../sub/a/b/c\" \"../foo/sub/a/b/c\"\n> >>  test_submodule_relative_url \"(null)\" \"../foo/bar\" \"../submodule\" \"../foo/submodule\"\n> >>  test_submodule_relative_url \"(null)\" \"../foo/submodule\" \"../submodule\" \"../foo/submodule\"\n> >>  test_submodule_relative_url \"(null)\" \"../foo\" \"../submodule\" \"../submodule\"\n> >\n> > I see that this already made it to `next`. I saw that because it breaks\n> > the build of Git for Windows (this was not noticed earlier because other\n> > compile failures prevented the tests from running), as now the test cases\n> > 173 and 177 of t0060 fail (*not* the newly introduced 163).\n> >\n> > Here is the output with -v -x:\n> >\n> > -- snip --\n> > [...]\n> > expecting success:\n> >                 actual=$(git submodule--helper resolve-relative-url-test '(null)' '/usr/src/git/wip/t/trash directory.t0060-path-utils/.' '../.') &&\n> >                 test \"$actual\" = 'C:/git-sdk-64/usr/src/git/wip/t/trash directory.t0060-path-utils/.'\n> >\n> > +++ git submodule--helper resolve-relative-url-test '(null)' '/usr/src/git/wip/t/trash directory.t0060-path-utils/.' ../.\n> > ++ actual=C:/git-sdk-64/usr/src/git/wip/t/.\n> > ++ test C:/git-sdk-64/usr/src/git/wip/t/. = 'C:/git-sdk-64/usr/src/git/wip/t/trash directory.t0060-path-utils/.'\n> \n> So this wipes away one dir too much in a test that doesn't end with a\n> dir separator\n\nThe problem is not *that* simple. You see, on Windows, there are no Unixy\npaths (I used to say POSIX but that is not correct, if you think of VMS\npaths looking quite a bit different from what Git expects). To appease\nGit's assumption about the exact form of paths, the Bash (actually, the\nPOSIX emulation layer called MSYS2) converts paths of the form\n/c/Windows/system32/drivers/etc/hosts to\nC:/Windows/system32/drivers/etc/hosts.\n\nPlease note that paths that are already in the latter form are not\ntouched.\n\nAnd note also that URLs (actually, anything matching \"^[A-Za-z]+://\") are\n*also* not converted.\n\nThe paths that *are* converted can also be of the form /etc/passwd, in\nwhich case the path is prefixed with the Windows directory in which whose\nusr/bin/ subdirectory the MSYS2 runtime lives.\n\nIn that latter case, i.e. Unixy paths being converted to Windows ones, the\nvery special case of a trailing \"/.\" is truncated to \"/\" (IIRC there are\nsome Windows programs that do not take well to \".\" referring to a\ndirectory, but my memory on that is flakey).\n\n> (In Windows that is '/' and '\\' only, no dots?)\n\nMost Windows functions handle forward slashes just fine. Certainly all\nfunctions involved in the code path in question.\n\n> > One very, very ugly workaround for this newly-introduced breakage would be\n> > this:\n> >\n> > -- snip --\n> > diff --git a/t/t0060-path-utils.sh b/t/t0060-path-utils.sh\n> > index 82b98f8..abd82e9 100755\n> > --- a/t/t0060-path-utils.sh\n> > +++ b/t/t0060-path-utils.sh\n> > @@ -328,11 +328,11 @@ test_submodule_relative_url \"(null)\" \"./foo\" \"../submodule\" \"submodule\"\n> >  test_submodule_relative_url \"(null)\" \"//somewhere else/repo\" \"../subrepo\" \"//somewhere else/subrepo\"\n> >  test_submodule_relative_url \"(null)\" \"$PWD/subsuper_update_r\" \"../subsubsuper_update_r\" \"$(pwd)/subsubsuper_update_r\"\n> >  test_submodule_relative_url \"(null)\" \"$PWD/super_update_r2\" \"../subsuper_update_r\" \"$(pwd)/subsuper_update_r\"\n> > -test_submodule_relative_url \"(null)\" \"$PWD/.\" \"../.\" \"$(pwd)/.\"\n> > +test_submodule_relative_url \"(null)\" \"$(pwd)/.\" \"../.\" \"$(pwd)/.\"\n> >  test_submodule_relative_url \"(null)\" \"$PWD\" \"./.\" \"$(pwd)/.\"\n> >  test_submodule_relative_url \"(null)\" \"$PWD/addtest\" \"../repo\" \"$(pwd)/repo\"\n> >  test_submodule_relative_url \"(null)\" \"$PWD\" \"./ \" \"$(pwd)/ \"\n> > -test_submodule_relative_url \"(null)\" \"$PWD/.\" \"../submodule\" \"$(pwd)/submodule\"\n> > +test_submodule_relative_url \"(null)\" \"$(pwd)/.\" \"../submodule\" \"$(pwd)/submodule\"\n> >  test_submodule_relative_url \"(null)\" \"$PWD/submodule\" \"../submodule\" \"$(pwd)/submodule\"\n> >  test_submodule_relative_url \"(null)\" \"$PWD/home2/../remote\" \"../bundle1\" \"$(pwd)/home2/../bundle1\"\n> >  test_submodule_relative_url \"(null)\" \"$PWD/submodule_update_repo\" \"./.\" \"$(pwd)/submodule_update_repo/.\"\n> > -- snap --\n> >\n> > The reasons this is ugly: we specifically test for *Unixy* paths when we\n> > use $PWD, as opposed to *Windowsy* paths when using $(pwd). We do this to\n> > ensure a certain level of confidence that running things such as\n> >\n> >         git clone --recurse-submodules /z/project/.\n> >\n> > work. And now that does not work anymore.\n> \n> After a while of thinking how I could fix it, it occurs to me, I could\n> claim the removal of the dot as a defect in the Windows path handling. ;)\n\nNot *quite*. It is not Windows' path handling. It is MSYS2's path\nhandling, and they must have had good reasons to introduce it. They do not\nstrip trailing dots just for fun.\n\n> But that doesn't help users.\n\nExactly.\n\n> Would it be possible to mark the last dir separator special once the\n> trailing dot is removed? (i.e. put a \\ there, and in this patch we\n> only check for /)\n> Sounds hacky to me, though.\n\nWe could claim that cloning recursively from absolute, Unixy paths is not\nsupported on Windows.\n\nGiven that it still works with relative paths and with absolute Windows\npaths and with URLs, I would claim that this is a fair trade-off.\n\nIn which case the ugly patch quoted above may be the best way forward.\n\n> > So where to go from here?\n> \n> So IIUC this patch fixed a bug in Git and introduced a very similar bug\n> in Git for Windows?\n\nYep. Even if it fixed the very same bug on Windows, too, as the trailing\ndot is kept for URLs and absolute Windows paths.\n\n> I have no expertise on how to deal with these path issues, but it sounds\n> like this dot-stripping is done too early, i.e. you'd want to first let\n> the Git part handle the URL concatenation and stuff and only at the end\n> when it comes to using the path it should get the Windows treatment?\n\nGit has no chance to fix this, as the Git executable (thanks to *not*\nusing the POSIX emulation layer) gets handed a Windows path without the\ntrailing dot when called from the Bash.\n\nThe same, obviously, goes for `git submodule-helper`: it is not using the\nPOSIX emulation layer, and therefore that layer converts the paths before\nexecuting said subcommand.\n\nAnd we cannot easily change the behavior of the MSYS2 runtime, as that\nwould affect too many other users, most likely breaking the use case that\nrequired the stripping of the trailing dot in the first place.\n\nSo I fear that we have to live with the fact that the bug you fixed just\nhid a bug on Windows, and that we have to either skip the tests or change\nthem in the way I proposed.\n\nOr we change the tests to work on a URL instead of a Unixy path.\n\nOpinions?\n\nCiao,\nDscho\n"},{"id":"304259","messageId":"xmqqfunvxxgu.fsf@gitster.mtv.corp.google.com","threadId":"44271","inReplyTo":"alpine.DEB.2.20.1610131255001.197091@virtualbox","subject":"Re: [PATCH 1/2] submodule: ignore trailing slash on superproject URL","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-10-17T07:10:09Z","receivedAt":"2016-10-17T07:10:19Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n>> > expecting success:\n>> >                 actual=$(git submodule--helper resolve-relative-url-test '(null)' '/usr/src/git/wip/t/trash directory.t0060-path-utils/.' '../.') &&\n>> >                 test \"$actual\" = 'C:/git-sdk-64/usr/src/git/wip/t/trash directory.t0060-path-utils/.'\n>> >\n>> > +++ git submodule--helper resolve-relative-url-test '(null)' '/usr/src/git/wip/t/trash directory.t0060-path-utils/.' ../.\n>> > ++ actual=C:/git-sdk-64/usr/src/git/wip/t/.\n>> > ++ test C:/git-sdk-64/usr/src/git/wip/t/. = 'C:/git-sdk-64/usr/src/git/wip/t/trash directory.t0060-path-utils/.'\n\nThis may well be total misunderstanding on my side, but is the\nexpectation of this test even correct?  If it wants to take \"../.\"\nrelative to \"$LEAD/t/trash utils/.\", should't it go one level up\nwith \"..\" to $LEAD/t and then stay there with \".\", expecting\n\"$LEAD/t\" which is what the above is giving us?\n\nIOW, the above makes me wonder why having one of these as the base\n\n\tA - path/to/dir\n\tB - path/to/dir/\n\tC - path/to/dir/.\n\nto resolve the relative \"../.\" give different results.  Whether bash\non Windows removes the dot at the end of C to turn it into B, as\nlong as A and B give us the same result we wouldn't be hitting the\nproblem, no?\n\n>> >  test_submodule_relative_url \"(null)\" \"$PWD/subsuper_update_r\" \"../subsubsuper_update_r\" \"$(pwd)/subsubsuper_update_r\"\n>> >  test_submodule_relative_url \"(null)\" \"$PWD/super_update_r2\" \"../subsuper_update_r\" \"$(pwd)/subsuper_update_r\"\n>> > -test_submodule_relative_url \"(null)\" \"$PWD/.\" \"../.\" \"$(pwd)/.\"\n>> > +test_submodule_relative_url \"(null)\" \"$(pwd)/.\" \"../.\" \"$(pwd)/.\"\n\n>> > The reasons this is ugly: we specifically test for *Unixy* paths when we\n>> > use $PWD, as opposed to *Windowsy* paths when using $(pwd).\n\nJust to ensure I am following this correctly, two tests that come\nbefore the one you are touching above have $PWD on the input side\nand $(pwd) on the expectation side.  That is what you mean by the\nnext paragraph, right?  They want to make sure that you honor the\nUnixy user input on Windows and still produce Windowsy result, that\nis.\n\n>> > We do this to\n>> > ensure a certain level of confidence that running things such as\n>> >\n>> >         git clone --recurse-submodules /z/project/.\n>> >\n>> > work. And now that does not work anymore.\n\nAnd I agree from that point of view that having to spell both sides\nas $(pwd) would mean you are not testing that \"Unixy input to\nWindowsy output\" expectation, but at the same time, I think you\nwould want \"Windowsy input to Windowsy output\" combination also does\nproduce correct result, which is not tested in the three tests shown\nabove.  IOW, probably you would want to test both (at least on any\nplatform where $PWD and $(pwd) textually disagree) for all these\n[*1*], and the pair\n\n    \"../.\" taken relative to \"$(pwd)/.\" must be \"$(pwd)/.\"\n    \"../.\" taken relative to \"$PWD/.\" must be \"$(pwd)/.\"\n\ntest, because of the limitation of your bash, cannot have the latter\nhalf of the pair, so you'd need to comment it out with in-code\nexplanation, perhaps?  IOW something along the lines of...\n\n -- >8 -- snip -- >8 --\n\ntest_submodule_relative_url \"(null)\" \"$(pwd)/subsuper_update_r\" \"../subsubsuper_update_r\" \"$(pwd)/subsubsuper_update_r\"\ntest_submodule_relative_url \"(null)\" \"$(pwd)/super_update_r2\" \"../subsuper_update_r\" \"$(pwd)/subsuper_update_r\"\ntest_submodule_relative_url \"(null)\" \"$(pwd)/.\" \"../.\" \"$(pwd)/.\"\n\nif test_have_prereq MINGW\nthen\n\ntest_submodule_relative_url \"(null)\" \"$PWD/subsuper_update_r\" \"../subsubsuper_update_r\" \"$(pwd)/subsubsuper_update_r\"\ntest_submodule_relative_url \"(null)\" \"$PWD/super_update_r2\" \"../subsuper_update_r\" \"$(pwd)/subsuper_update_r\"\n# This does not work correctly because Win-Bash strips . at the end\n# \"of $PWD/.\"\n# test_submodule_relative_url \"(null)\" \"$PWD/.\" \"../.\" \"$(pwd)/.\"\n\nfi\n\n -- >8 -- snip -- >8 --\n\nIn any case, I find it more disturbing that we somehow ended up with\na system where these three things are expected to behave differently:\n\n\tA - path/to/dir\n\tB - path/to/dir/\n\tC - path/to/dir/.\n\nIs that something we can fix?\n\n\n[Footnote]\n\n*1* It is tempting to update the above test sequence using\n    a helper like:\n\n    tsru () {\n\ttest_submodule_relative_url \"(null)\" \"$(pwd)/$1\" \"$2\" \"$(pwd)/$3\"\n\tif test_have_prereq MINGW\n\tthen\n\t    test_submodule_relative_url \"(null)\" \"$PWD/$1\" \"$2\" \"$(pwd)/$3\"\n\tfi\n    }\n\n    then write the above three tests like so:\n\n\ttsru subsuper_update_r ../subsubsuper_update_r subsubsuper_update_r\n\ttsru super_update_r2 ../subsuper_update_r subsuper_update_r\n\ttsru . ../. .\n\n    but you would want to disable the MINGW half for only the third\n    test, we cannot quite do that.\n"},{"id":"304292","messageId":"CAGZ79kYW2qK1GKxoKy_mkVkjjqEUzkh5aPSzDEfRd6U=PYDdzw@mail.gmail.com","threadId":"44271","inReplyTo":"xmqqfunvxxgu.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH 1/2] submodule: ignore trailing slash on superproject URL","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2016-10-17T17:58:59Z","receivedAt":"2016-10-17T17:59:07Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Mon, Oct 17, 2016 at 12:10 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n>\n>>> > expecting success:\n>>> >                 actual=$(git submodule--helper resolve-relative-url-test '(null)' '/usr/src/git/wip/t/trash directory.t0060-path-utils/.' '../.') &&\n>>> >                 test \"$actual\" = 'C:/git-sdk-64/usr/src/git/wip/t/trash directory.t0060-path-utils/.'\n>>> >\n>>> > +++ git submodule--helper resolve-relative-url-test '(null)' '/usr/src/git/wip/t/trash directory.t0060-path-utils/.' ../.\n>>> > ++ actual=C:/git-sdk-64/usr/src/git/wip/t/.\n>>> > ++ test C:/git-sdk-64/usr/src/git/wip/t/. = 'C:/git-sdk-64/usr/src/git/wip/t/trash directory.t0060-path-utils/.'\n>\n> This may well be total misunderstanding on my side, but is the\n> expectation of this test even correct?  If it wants to take \"../.\"\n> relative to \"$LEAD/t/trash utils/.\", should't it go one level up\n> with \"..\" to $LEAD/t and then stay there with \".\", expecting\n> \"$LEAD/t\" which is what the above is giving us?\n>\n> IOW, the above makes me wonder why having one of these as the base\n>\n>         A - path/to/dir\n>         B - path/to/dir/\n>         C - path/to/dir/.\n>\n> to resolve the relative \"../.\" give different results.\n\nBecause the shell script originally did \"just\"\n\nrelative=\"../.\"\nif path/to/dir/ ends with slash, chop it off.\nwhile $relative starts with \"../\";\ndo\n    chop off starting '../' of relative\n    chop of last '/' and following from \"path/to/dir/.\"\ndone\n\n(Linux:)\nAs B was made to A first, only C differs as a result, because\nyou had one more '/' in there.\n\n(Windows:)\nHowever Windows also detects '/.' (C) and makes it an A,\n(in C only, because shell code was not treated Windows-sy)\nwhich is where the incompatibility between Windows and other\nplatforms arises.\n\nSo we have a couple of choices (for Git)now:\n* go back to using shell only for submodule things as that doesn't\n  have the regression and it alos plays nicely with Git for Windows.\n* use C for the submodule code in Git and revert the regression fix\n  \"because consistency across platforms trumps\n  consistency over time\"\n* use C for the submodule code in Git and keep the regression fix\n  \"because consistency over time in Git proper is more important\n  than playing nicely with Git for Windows\"\n* would it be possible to revert this to shell on Windows only?\n\n> Whether bash\n> on Windows removes the dot at the end of C to turn it into B, as\n> long as A and B give us the same result we wouldn't be hitting the\n> problem, no?\n\nWell in Git proper A,B are the same and C is different.\n(B was fixed as a regression)\nIn Windows C is like B, which was different without the regression\nfix, but now it is the same as A, too.\n\n>\n>>> >  test_submodule_relative_url \"(null)\" \"$PWD/subsuper_update_r\" \"../subsubsuper_update_r\" \"$(pwd)/subsubsuper_update_r\"\n>>> >  test_submodule_relative_url \"(null)\" \"$PWD/super_update_r2\" \"../subsuper_update_r\" \"$(pwd)/subsuper_update_r\"\n>>> > -test_submodule_relative_url \"(null)\" \"$PWD/.\" \"../.\" \"$(pwd)/.\"\n>>> > +test_submodule_relative_url \"(null)\" \"$(pwd)/.\" \"../.\" \"$(pwd)/.\"\n>\n>>> > The reasons this is ugly: we specifically test for *Unixy* paths when we\n>>> > use $PWD, as opposed to *Windowsy* paths when using $(pwd).\n>\n> Just to ensure I am following this correctly, two tests that come\n> before the one you are touching above have $PWD on the input side\n> and $(pwd) on the expectation side.  That is what you mean by the\n> next paragraph, right?  They want to make sure that you honor the\n> Unixy user input on Windows and still produce Windowsy result, that\n> is.\n>\n>>> > We do this to\n>>> > ensure a certain level of confidence that running things such as\n>>> >\n>>> >         git clone --recurse-submodules /z/project/.\n>>> >\n>>> > work. And now that does not work anymore.\n>\n> And I agree from that point of view that having to spell both sides\n> as $(pwd) would mean you are not testing that \"Unixy input to\n> Windowsy output\" expectation, but at the same time, I think you\n> would want \"Windowsy input to Windowsy output\" combination also does\n> produce correct result, which is not tested in the three tests shown\n> above.  IOW, probably you would want to test both (at least on any\n> platform where $PWD and $(pwd) textually disagree) for all these\n> [*1*], and the pair\n>\n>     \"../.\" taken relative to \"$(pwd)/.\" must be \"$(pwd)/.\"\n>     \"../.\" taken relative to \"$PWD/.\" must be \"$(pwd)/.\"\n>\n> test, because of the limitation of your bash, cannot have the latter\n> half of the pair, so you'd need to comment it out with in-code\n> explanation, perhaps?  IOW something along the lines of...\n>\n>  -- >8 -- snip -- >8 --\n>\n> test_submodule_relative_url \"(null)\" \"$(pwd)/subsuper_update_r\" \"../subsubsuper_update_r\" \"$(pwd)/subsubsuper_update_r\"\n> test_submodule_relative_url \"(null)\" \"$(pwd)/super_update_r2\" \"../subsuper_update_r\" \"$(pwd)/subsuper_update_r\"\n> test_submodule_relative_url \"(null)\" \"$(pwd)/.\" \"../.\" \"$(pwd)/.\"\n>\n> if test_have_prereq MINGW\n> then\n>\n> test_submodule_relative_url \"(null)\" \"$PWD/subsuper_update_r\" \"../subsubsuper_update_r\" \"$(pwd)/subsubsuper_update_r\"\n> test_submodule_relative_url \"(null)\" \"$PWD/super_update_r2\" \"../subsuper_update_r\" \"$(pwd)/subsuper_update_r\"\n> # This does not work correctly because Win-Bash strips . at the end\n> # \"of $PWD/.\"\n> # test_submodule_relative_url \"(null)\" \"$PWD/.\" \"../.\" \"$(pwd)/.\"\n>\n> fi\n>\n>  -- >8 -- snip -- >8 --\n>\n> In any case, I find it more disturbing that we somehow ended up with\n> a system where these three things are expected to behave differently:\n>\n>         A - path/to/dir\n>         B - path/to/dir/\n>         C - path/to/dir/.\n>\n> Is that something we can fix?\n\nWell A, B are the same.\nC is \"obviously\" different, when it comes to counting slashes for relative\npath/url purposes, in the way that there are characters after the last slash\nand just by coincidence '.' refers to the directory itself, C behaving like\n'path/to/dir/sub' seems right to me.\n\nSo how do you imagine this fix going forward?\n* Breaking existing users with /. at the end? by treating it the same as A,B\n* Do some check based on time/version of Git and cover the old data?\n* Forbid /. at the end from now on?\n\n>\n>\n> [Footnote]\n>\n> *1* It is tempting to update the above test sequence using\n>     a helper like:\n>\n>     tsru () {\n>         test_submodule_relative_url \"(null)\" \"$(pwd)/$1\" \"$2\" \"$(pwd)/$3\"\n>         if test_have_prereq MINGW\n>         then\n>             test_submodule_relative_url \"(null)\" \"$PWD/$1\" \"$2\" \"$(pwd)/$3\"\n>         fi\n>     }\n>\n>     then write the above three tests like so:\n>\n>         tsru subsuper_update_r ../subsubsuper_update_r subsubsuper_update_r\n>         tsru super_update_r2 ../subsuper_update_r subsuper_update_r\n>         tsru . ../. .\n>\n>     but you would want to disable the MINGW half for only the third\n>     test, we cannot quite do that.\n"},{"id":"304295","messageId":"xmqqh98avnhh.fsf@gitster.mtv.corp.google.com","threadId":"44271","inReplyTo":"CAGZ79kYW2qK1GKxoKy_mkVkjjqEUzkh5aPSzDEfRd6U=PYDdzw@mail.gmail.com","subject":"Re: [PATCH 1/2] submodule: ignore trailing slash on superproject URL","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-10-17T18:28:42Z","receivedAt":"2016-10-17T18:28:51Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Beller <sbeller@google.com> writes:\n\n>> In any case, I find it more disturbing that we somehow ended up with\n>> a system where these three things are expected to behave differently:\n>>\n>>         A - path/to/dir\n>>         B - path/to/dir/\n>>         C - path/to/dir/.\n>>\n>> Is that something we can fix?\n>\n> Well A, B are the same.\n> C is \"obviously\" different, when it comes to counting slashes for relative\n> path/url purposes, in the way that there are characters after the last slash\n> and just by coincidence '.' refers to the directory itself, C behaving like\n> 'path/to/dir/sub' seems right to me.\n\nIt doesn't look right to me at all.  If you were contrasting\n\n\tcd path/to/dir/sub && cd ..\n\tcd path/to/dir/bus && cd ..\n\nthen I would understand, but why should these two\n\n\tcd path/to/dir/. && cd ..\n\tcd path/to/dir/sub && cd ..\n\nbehave the same?\n\n> So how do you imagine this fix going forward?\n> * Breaking existing users with /. at the end? by treating it the same as A,B\n> * Do some check based on time/version of Git and cover the old data?\n> * Forbid /. at the end from now on?\n\nWhere at the end-user facing level does this trailing \"/.\" surface\nand how does the difference appear to them?  I think that is the\ncrucial question.\n\nUnless there is some convincing argument why \".\" is not special\n(i.e. counter-argument to the above \"bus vs sub\" and \". vs sub\"\nexample), I would think \"existing users with /.\" does not matter.\nIf they are \"relying\" on the behaviour, I would think it is not\nbecause they find that behaviour intuitive, but only because they\nlearned to live with it.  IOW, treating all of A/B/C the same way\nwould appear to them a strict bugfix, I would think.\n\nIt is totally a different matter if OUR code that consumes the\noutput from the submodule-helper --resolve-relative\" internally is\nconfused and relies on \"../. relative to path/to/dir/. is the same\nas ../. relative to path/to/dir/sub\" for whatever reason.  Without\nfixing that, I would not surprised if fixing things to treat A/B/C\nthe same way would surface differences in the end-user observable\nbehaviour in a negative way.\n\n"},{"id":"304297","messageId":"CAGZ79kZvRf0gHA7tBh1veS9YzAWZ0j0SMGL3c9QQOrERMjmuyQ@mail.gmail.com","threadId":"44271","inReplyTo":"xmqqh98avnhh.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH 1/2] submodule: ignore trailing slash on superproject URL","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2016-10-17T18:58:52Z","receivedAt":"2016-10-17T18:58:59Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Mon, Oct 17, 2016 at 11:28 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> Stefan Beller <sbeller@google.com> writes:\n>\n>>> In any case, I find it more disturbing that we somehow ended up with\n>>> a system where these three things are expected to behave differently:\n>>>\n>>>         A - path/to/dir\n>>>         B - path/to/dir/\n>>>         C - path/to/dir/.\n>>>\n>>> Is that something we can fix?\n>>\n>> Well A, B are the same.\n>> C is \"obviously\" different, when it comes to counting slashes for relative\n>> path/url purposes, in the way that there are characters after the last slash\n>> and just by coincidence '.' refers to the directory itself, C behaving like\n>> 'path/to/dir/sub' seems right to me.\n>\n> It doesn't look right to me at all.  If you were contrasting\n>\n>         cd path/to/dir/sub && cd ..\n>         cd path/to/dir/bus && cd ..\n>\n> then I would understand, but why should these two\n>\n>         cd path/to/dir/. && cd ..\n>         cd path/to/dir/sub && cd ..\n>\n> behave the same?\n>\n>> So how do you imagine this fix going forward?\n>> * Breaking existing users with /. at the end? by treating it the same as A,B\n>> * Do some check based on time/version of Git and cover the old data?\n>> * Forbid /. at the end from now on?\n>\n> Where at the end-user facing level does this trailing \"/.\" surface\n> and how does the difference appear to them?  I think that is the\n> crucial question.\n>\n> Unless there is some convincing argument why \".\" is not special\n> (i.e. counter-argument to the above \"bus vs sub\" and \". vs sub\"\n> example), I would think \"existing users with /.\" does not matter.\n> If they are \"relying\" on the behaviour, I would think it is not\n> because they find that behaviour intuitive, but only because they\n> learned to live with it.  IOW, treating all of A/B/C the same way\n> would appear to them a strict bugfix, I would think.\n\nI see, so we should adapt the windows style and chop off '/.'\nto make A,B,C all the same, because internally we never produced\nC AFAICT.\n\nThese came in via hand edited .gitmodules files.\n\n>\n> It is totally a different matter if OUR code that consumes the\n> output from the submodule-helper --resolve-relative\" internally is\n> confused and relies on \"../. relative to path/to/dir/. is the same\n> as ../. relative to path/to/dir/sub\" for whatever reason.  Without\n> fixing that, I would not surprised if fixing things to treat A/B/C\n> the same way would surface differences in the end-user observable\n> behaviour in a negative way.\n>\n"},{"id":"304300","messageId":"xmqqvawqu6pz.fsf@gitster.mtv.corp.google.com","threadId":"44271","inReplyTo":"CAGZ79kZvRf0gHA7tBh1veS9YzAWZ0j0SMGL3c9QQOrERMjmuyQ@mail.gmail.com","subject":"Re: [PATCH 1/2] submodule: ignore trailing slash on superproject URL","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-10-17T19:16:08Z","receivedAt":"2016-10-17T19:16:22Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Beller <sbeller@google.com> writes:\n\n>> Where at the end-user facing level does this trailing \"/.\" surface\n>> and how does the difference appear to them?  I think that is the\n>> crucial question.\n>>\n>> Unless there is some convincing argument why \".\" is not special\n>> (i.e. counter-argument to the above \"bus vs sub\" and \". vs sub\"\n>> example), I would think \"existing users with /.\" does not matter.\n>> If they are \"relying\" on the behaviour, I would think it is not\n>> because they find that behaviour intuitive, but only because they\n>> learned to live with it.  IOW, treating all of A/B/C the same way\n>> would appear to them a strict bugfix, I would think.\n>\n> I see, so we should adapt the windows style and chop off '/.'\n> to make A,B,C all the same, because internally we never produced\n> C AFAICT.\n>\n> These came in via hand edited .gitmodules files.\n\nCan you elaborate a bit more on this?  \n\nWithout seeing \"The user added X/. instead of the usual X because\ns/he wanted to see Y happen.  If s/he had X there, Z would have\nhappened instead of Y\" and why being able to expect Y to happen is a\ngood thing (compared to Z), we may fail to notice why the more\n\"intuitive\" (at least to me) \"these three must result in the same\noutcome: path/to/dir, path/to/dir/, or path/to/dir/.\" does not serve\na legitimate use case.\n"},{"id":"304301","messageId":"2aa41392-a7ed-cd48-2737-bd852757ab35@kdbg.org","threadId":"44271","inReplyTo":"xmqqfunvxxgu.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH 1/2] submodule: ignore trailing slash on superproject URL","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2016-10-17T19:32:52Z","receivedAt":"2016-10-17T19:33:00Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 17.10.2016 um 09:10 schrieb Junio C Hamano:\n> And I agree from that point of view that having to spell both sides\n> as $(pwd) would mean you are not testing that \"Unixy input to\n> Windowsy output\" expectation, but at the same time, I think you\n> would want \"Windowsy input to Windowsy output\" combination also does\n> produce correct result, which is not tested in the three tests shown\n> above.  IOW, probably you would want to test both (at least on any\n> platform where $PWD and $(pwd) textually disagree) for all these\n> [*1*], and the pair\n>\n>     \"../.\" taken relative to \"$(pwd)/.\" must be \"$(pwd)/.\"\n>     \"../.\" taken relative to \"$PWD/.\" must be \"$(pwd)/.\"\n>\n> test, because of the limitation of your bash, cannot have the latter\n> half of the pair, so you'd need to comment it out with in-code\n> explanation, perhaps?\n\nNo, we do not have to test both cases. Git, the program, never sees \nUnixy input. It cannot distinguish the two cases. If we did both tests, \nwe would just test that *if* the front-end of git is an MSYS program \n(such as bash), *then* that MSYS front-end has converted the Unixy path \nto a Windows-y path in such a way that the end-result is also as \nexpected. It's similar to a test that grep produces expected output.\n\nI think that we could reduce the confusion by converting all $PWD to \n$(pwd) in these test cases. I don't remember why I suggested to use $PWD \nfor one of the arguments of the test cases (the second must be $(pwd)), \nbut the most likely reason is only that we save a process.\n\n-- Hannes\n\n"},{"id":"304304","messageId":"xmqqr37eu4d3.fsf@gitster.mtv.corp.google.com","threadId":"44271","inReplyTo":"2aa41392-a7ed-cd48-2737-bd852757ab35@kdbg.org","subject":"Re: [PATCH 1/2] submodule: ignore trailing slash on superproject URL","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-10-17T20:07:04Z","receivedAt":"2016-10-17T20:07:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt <j6t@kdbg.org> writes:\n\n>>     \"../.\" taken relative to \"$(pwd)/.\" must be \"$(pwd)/.\"\n>>     \"../.\" taken relative to \"$PWD/.\" must be \"$(pwd)/.\"\n>>\n>> test, because of the limitation of your bash, cannot have the latter\n>> half of the pair, so you'd need to comment it out with in-code\n>> explanation, perhaps?\n>\n> No, we do not have to test both cases. Git, the program, never sees\n> Unixy input. It cannot distinguish the two cases.\n\nThanks.\n"},{"id":"304359","messageId":"2908451e-4273-8826-8989-5572263cc283@kdbg.org","threadId":"44271","inReplyTo":"2aa41392-a7ed-cd48-2737-bd852757ab35@kdbg.org","subject":"Re: [PATCH 1/2] submodule: ignore trailing slash on superproject URL","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2016-10-18T20:06:07Z","receivedAt":"2016-10-18T20:06:16Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 17.10.2016 um 21:32 schrieb Johannes Sixt:\n> I think that we could reduce the confusion by converting all $PWD to\n> $(pwd) in these test cases. I don't remember why I suggested to use $PWD\n> for one of the arguments of the test cases (the second must be $(pwd)),\n> but the most likely reason is only that we save a process.\n\nSomething like this works for me on Windows. I can update the patch\nafter the \"normalize funny urls\" topic settles.\n\n---- 8< ----\nt0060: sidestep surprising path mangling results on Windows\n\nWhen an MSYS program (such as the bash that drives the test suite)\ninvokes git on Windows, absolute Unix style paths are transformed into\nWindows native absolute paths (drive letter form). However, this\ntransformation also includes some simplifications that are not just\nstraight-forward textual substitutions:\n\n- When the path ends in \"/.\", then the dot is stripped, but not the\n  directory separator.\n\n- When the path contains \"..\", then it is optimized away if possible,\n  e.g., \"/c/dir/foo/../bar\" becomes \"c:/dir/bar\".\n\nThese additional transformations violate the assumptions of some\nsubmodule path tests. We can avoid them when the input is already a\nWindows native path, because then MSYS leaves the path unmolested.\n\nConvert the uses of $PWD to $(pwd); the latter returns a native Windows\npath.\n\nSigned-off-by: Johannes Sixt <j6t@kdbg.org>\n---\n t/t0060-path-utils.sh | 27 ++++++++++++++-------------\n 1 file changed, 14 insertions(+), 13 deletions(-)\n\ndiff --git a/t/t0060-path-utils.sh b/t/t0060-path-utils.sh\nindex 25b48e5..444b5a4 100755\n--- a/t/t0060-path-utils.sh\n+++ b/t/t0060-path-utils.sh\n@@ -305,8 +305,9 @@ test_git_path GIT_COMMON_DIR=bar config                   bar/config\n test_git_path GIT_COMMON_DIR=bar packed-refs              bar/packed-refs\n test_git_path GIT_COMMON_DIR=bar shallow                  bar/shallow\n \n-# In the tests below, the distinction between $PWD and $(pwd) is important:\n-# on Windows, $PWD is POSIX style (/c/foo), $(pwd) has drive letter (c:/foo).\n+# In the tests below, $(pwd) must be used because it is a native path on\n+# Windows and avoids MSYS's path mangling (which simplifies \"foo/../bar\" and\n+# strips the dot from trailing \"/.\").\n \n test_submodule_relative_url \"../\" \"../foo\" \"../submodule\" \"../../submodule\"\n test_submodule_relative_url \"../\" \"../foo/bar\" \"../submodule\" \"../../foo/submodule\"\n@@ -314,7 +315,7 @@ test_submodule_relative_url \"../\" \"../foo/submodule\" \"../submodule\" \"../../foo/s\n test_submodule_relative_url \"../\" \"./foo\" \"../submodule\" \"../submodule\"\n test_submodule_relative_url \"../\" \"./foo/bar\" \"../submodule\" \"../foo/submodule\"\n test_submodule_relative_url \"../../../\" \"../foo/bar\" \"../sub/a/b/c\" \"../../../../foo/sub/a/b/c\"\n-test_submodule_relative_url \"../\" \"$PWD/addtest\" \"../repo\" \"$(pwd)/repo\"\n+test_submodule_relative_url \"../\" \"$(pwd)/addtest\" \"../repo\" \"$(pwd)/repo\"\n test_submodule_relative_url \"../\" \"foo/bar\" \"../submodule\" \"../foo/submodule\"\n test_submodule_relative_url \"../\" \"foo\" \"../submodule\" \"../submodule\"\n \n@@ -327,16 +328,16 @@ test_submodule_relative_url \"(null)\" \"../foo\" \"../submodule\" \"../submodule\"\n test_submodule_relative_url \"(null)\" \"./foo/bar\" \"../submodule\" \"foo/submodule\"\n test_submodule_relative_url \"(null)\" \"./foo\" \"../submodule\" \"submodule\"\n test_submodule_relative_url \"(null)\" \"//somewhere else/repo\" \"../subrepo\" \"//somewhere else/subrepo\"\n-test_submodule_relative_url \"(null)\" \"$PWD/subsuper_update_r\" \"../subsubsuper_update_r\" \"$(pwd)/subsubsuper_update_r\"\n-test_submodule_relative_url \"(null)\" \"$PWD/super_update_r2\" \"../subsuper_update_r\" \"$(pwd)/subsuper_update_r\"\n-test_submodule_relative_url \"(null)\" \"$PWD/.\" \"../.\" \"$(pwd)/.\"\n-test_submodule_relative_url \"(null)\" \"$PWD\" \"./.\" \"$(pwd)/.\"\n-test_submodule_relative_url \"(null)\" \"$PWD/addtest\" \"../repo\" \"$(pwd)/repo\"\n-test_submodule_relative_url \"(null)\" \"$PWD\" \"./å äö\" \"$(pwd)/å äö\"\n-test_submodule_relative_url \"(null)\" \"$PWD/.\" \"../submodule\" \"$(pwd)/submodule\"\n-test_submodule_relative_url \"(null)\" \"$PWD/submodule\" \"../submodule\" \"$(pwd)/submodule\"\n-test_submodule_relative_url \"(null)\" \"$PWD/home2/../remote\" \"../bundle1\" \"$(pwd)/home2/../bundle1\"\n-test_submodule_relative_url \"(null)\" \"$PWD/submodule_update_repo\" \"./.\" \"$(pwd)/submodule_update_repo/.\"\n+test_submodule_relative_url \"(null)\" \"$(pwd)/subsuper_update_r\" \"../subsubsuper_update_r\" \"$(pwd)/subsubsuper_update_r\"\n+test_submodule_relative_url \"(null)\" \"$(pwd)/super_update_r2\" \"../subsuper_update_r\" \"$(pwd)/subsuper_update_r\"\n+test_submodule_relative_url \"(null)\" \"$(pwd)/.\" \"../.\" \"$(pwd)/.\"\n+test_submodule_relative_url \"(null)\" \"$(pwd)\" \"./.\" \"$(pwd)/.\"\n+test_submodule_relative_url \"(null)\" \"$(pwd)/addtest\" \"../repo\" \"$(pwd)/repo\"\n+test_submodule_relative_url \"(null)\" \"$(pwd)\" \"./å äö\" \"$(pwd)/å äö\"\n+test_submodule_relative_url \"(null)\" \"$(pwd)/.\" \"../submodule\" \"$(pwd)/submodule\"\n+test_submodule_relative_url \"(null)\" \"$(pwd)/submodule\" \"../submodule\" \"$(pwd)/submodule\"\n+test_submodule_relative_url \"(null)\" \"$(pwd)/home2/../remote\" \"../bundle1\" \"$(pwd)/home2/../bundle1\"\n+test_submodule_relative_url \"(null)\" \"$(pwd)/submodule_update_repo\" \"./.\" \"$(pwd)/submodule_update_repo/.\"\n test_submodule_relative_url \"(null)\" \"file:///tmp/repo\" \"../subrepo\" \"file:///tmp/subrepo\"\n test_submodule_relative_url \"(null)\" \"foo/bar\" \"../submodule\" \"foo/submodule\"\n test_submodule_relative_url \"(null)\" \"foo\" \"../submodule\" \"submodule\"\n-- \n2.10.0.343.g37bc62b\n\n"}]}