{"thread":{"id":"53013","subject":"Relative url values in .gitmodules confusingly sensitive to clone via ssh vs https.","startedAt":"2020-03-17T18:34:24Z","lastAt":"2020-03-23T23:54:06Z","messageCount":7,"participants":["Benjamin Shropshire","brian m. carlson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"393366","messageId":"CAAjm7Ga5JOJ2w=01o1-x-80HMGVaYQQy8SBBb-zJ6MOQAe4SxQ@mail.gmail.com","threadId":"53013","inReplyTo":null,"subject":"Relative url values in .gitmodules confusingly sensitive to clone via ssh vs https.","fromName":"Benjamin Shropshire","fromEmail":"benjamin.shropshire@economicmodeling.com","sentAt":"2020-03-17T18:34:09Z","receivedAt":"2020-03-17T18:34:24Z","isPatch":false,"sender":{"key":"benjamin.shropshire@economicmodeling.com","avatar":null},"body":"From my perspective, this is a bug.\n\nIf I clone a repo twice like this:\n\ngit clone https://github.com/user/repo.git ./https\ngit clone git@github.com:user/repo.git ./ssh\n\nAnd if it contains a .gitmodules like this:\n\n[submodule \"x\"]\n    path = xxx\n    url = ../../different-user/something.git\n\nWhen I `git submodule update --init --recursive` in each, only the\nHTTPS version works. the SSH version confusingly seems to try to find\nsomething at ~/different-user/something.git or some other path in the\nlocal file system.\n\nthis seems consistent with the URL parsing resulting in different\nsegmentation and thus the ../../ ending up in different places:\n\nhttps =[..., 'github.com', 'user', 'repo.git']\nssh=['git@github.com:user', 'repo.git']\n\n# ../../\nhttps[:-2] -> [..., 'github.com']\nssh[:-2] -> []\n\nThis theory is supported by the fact that this works:\n\ngit clone ssh://git@github.com/user/repo.git ./ssh\ncd ssh\ngit submodule update --init --recursive\n\n----\nSee also: https://stackoverflow.com/questions/36564696/how-to-use-same-protocol-for-git-submodules\n"},{"id":"393380","messageId":"20200318002630.GA366567@camp.crustytoothpaste.net","threadId":"53013","inReplyTo":"CAAjm7Ga5JOJ2w=01o1-x-80HMGVaYQQy8SBBb-zJ6MOQAe4SxQ@mail.gmail.com","subject":"Re: Relative url values in .gitmodules confusingly sensitive to clone via ssh vs https.","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2020-03-18T00:26:30Z","receivedAt":"2020-03-18T00:26:38Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2020-03-17 at 18:34:09, Benjamin Shropshire wrote:\n> From my perspective, this is a bug.\n> \n> If I clone a repo twice like this:\n> \n> git clone https://github.com/user/repo.git ./https\n> git clone git@github.com:user/repo.git ./ssh\n> \n> And if it contains a .gitmodules like this:\n> \n> [submodule \"x\"]\n>     path = xxx\n>     url = ../../different-user/something.git\n> \n> When I `git submodule update --init --recursive` in each, only the\n> HTTPS version works. the SSH version confusingly seems to try to find\n> something at ~/different-user/something.git or some other path in the\n> local file system.\n> \n> this seems consistent with the URL parsing resulting in different\n> segmentation and thus the ../../ ending up in different places:\n\nLooking at the code, it appears that we don't let you go above the top\nof the URL, which makes sense.  So we interpret it as a file system\npath.\n\n(And since this SSH format is not technically a URL, we don't have a\nroot slash, which is probably why this is a problem.)\n\nDoes it work if you write the following?\n\n  git clone git@github.com:/user/repo.git ./ssh\n-- \nbrian m. carlson: Houston, Texas, US\nOpenPGP: https://keybase.io/bk2204\n"},{"id":"393400","messageId":"CAAjm7Gb8DdGUCfoPO+p2=YsmvFj5eoCn3jjEbwg3-hwRnt0Q9A@mail.gmail.com","threadId":"53013","inReplyTo":"20200318002630.GA366567@camp.crustytoothpaste.net","subject":"Re: Relative url values in .gitmodules confusingly sensitive to clone via ssh vs https.","fromName":"Benjamin Shropshire","fromEmail":"benjamin.shropshire@economicmodeling.com","sentAt":"2020-03-18T16:02:18Z","receivedAt":"2020-03-18T16:02:35Z","isPatch":false,"sender":{"key":"benjamin.shropshire@economicmodeling.com","avatar":null},"body":"On Tue, Mar 17, 2020 at 5:26 PM brian m. carlson\n<sandals@crustytoothpaste.net> wrote:\n> On 2020-03-17 at 18:34:09, Benjamin Shropshire wrote:\n> > From my perspective, this is a bug.\n> >\n> > If I clone a repo twice like this:\n> >\n> > git clone https://github.com/user/repo.git ./https\n> > git clone git@github.com:user/repo.git ./ssh\n> >\n> > And if it contains a .gitmodules like this:\n> >\n> > [submodule \"x\"]\n> >     path = xxx\n> >     url = ../../different-user/something.git\n> >\n> > When I `git submodule update --init --recursive` in each, only the\n> > HTTPS version works. the SSH version confusingly seems to try to find\n> > something at ~/different-user/something.git or some other path in the\n> > local file system.\n> >\n> > this seems consistent with the URL parsing resulting in different\n> > segmentation and thus the ../../ ending up in different places:\n>\n> Looking at the code, it appears that we don't let you go above the top\n> of the URL, which makes sense.  So we interpret it as a file system\n> path.\n>\n> (And since this SSH format is not technically a URL, we don't have a\n> root slash, which is probably why this is a problem.)\n>\n> Does it work if you write the following?\n>\n>   git clone git@github.com:/user/repo.git ./ssh\n\nThat seems to work... thought if the final resolution is telling\npeople to just use a particular format for the repo address, I'd vote\nfor telling them to use a full and proper ssh:// URL. (Technically I\nthink `git@host:/...` may be a protocol relative URL? or maybe that\nwould need to be `//git@host:/....`?)\n\n> --\n> brian m. carlson: Houston, Texas, US\n> OpenPGP: https://keybase.io/bk2204\n"},{"id":"393505","messageId":"20200320011809.GG366567@camp.crustytoothpaste.net","threadId":"53013","inReplyTo":"CAAjm7Gb8DdGUCfoPO+p2=YsmvFj5eoCn3jjEbwg3-hwRnt0Q9A@mail.gmail.com","subject":"Re: Relative url values in .gitmodules confusingly sensitive to clone via ssh vs https.","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2020-03-20T01:18:09Z","receivedAt":"2020-03-20T01:18:18Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2020-03-18 at 16:02:18, Benjamin Shropshire wrote:\n> On Tue, Mar 17, 2020 at 5:26 PM brian m. carlson\n> <sandals@crustytoothpaste.net> wrote:\n> > Looking at the code, it appears that we don't let you go above the top\n> > of the URL, which makes sense.  So we interpret it as a file system\n> > path.\n> >\n> > (And since this SSH format is not technically a URL, we don't have a\n> > root slash, which is probably why this is a problem.)\n> >\n> > Does it work if you write the following?\n> >\n> >   git clone git@github.com:/user/repo.git ./ssh\n> \n> That seems to work... thought if the final resolution is telling\n> people to just use a particular format for the repo address, I'd vote\n> for telling them to use a full and proper ssh:// URL. (Technically I\n> think `git@host:/...` may be a protocol relative URL? or maybe that\n> would need to be `//git@host:/....`?)\n\nI do intend to send a patch to make your particular use case work such\nthat we consider a colon equivalent to a leading slash, but I have a\nlittle less time than usual (mostly due to current events).  I hope to\nfind some time this weekend, although of course anyone is welcome to\nsend a patch sooner if they get to it first.\n\nI agree that the URL form is probably better overall, but I suspect I'm\nin the minority there.\n-- \nbrian m. carlson: Houston, Texas, US\nOpenPGP: https://keybase.io/bk2204\n"},{"id":"393753","messageId":"20200323011117.GC6499@camp.crustytoothpaste.net","threadId":"53013","inReplyTo":"CAAjm7Ga5JOJ2w=01o1-x-80HMGVaYQQy8SBBb-zJ6MOQAe4SxQ@mail.gmail.com","subject":"Re: Relative url values in .gitmodules confusingly sensitive to clone via ssh vs https.","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2020-03-23T01:11:17Z","receivedAt":"2020-03-23T01:11:26Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2020-03-17 at 18:34:09, Benjamin Shropshire wrote:\n> From my perspective, this is a bug.\n> \n> If I clone a repo twice like this:\n> \n> git clone https://github.com/user/repo.git ./https\n> git clone git@github.com:user/repo.git ./ssh\n> \n> And if it contains a .gitmodules like this:\n> \n> [submodule \"x\"]\n>     path = xxx\n>     url = ../../different-user/something.git\n> \n> When I `git submodule update --init --recursive` in each, only the\n> HTTPS version works. the SSH version confusingly seems to try to find\n> something at ~/different-user/something.git or some other path in the\n> local file system.\n\nWhat version of Git are you using?  This works fine for me on a recent\nnext.  In addition, I see we have tests for this in t0060, and adding an\nadditional case for this appears to pass.\n-- \nbrian m. carlson: Houston, Texas, US\nOpenPGP: https://keybase.io/bk2204\n"},{"id":"393773","messageId":"CAAjm7GZXNXcGMp7p2f+UoDUWMPY+Z4aFHv35tynteVSKDf2Fqw@mail.gmail.com","threadId":"53013","inReplyTo":"20200323011117.GC6499@camp.crustytoothpaste.net","subject":"Re: Relative url values in .gitmodules confusingly sensitive to clone via ssh vs https.","fromName":"Benjamin Shropshire","fromEmail":"benjamin.shropshire@economicmodeling.com","sentAt":"2020-03-23T15:09:39Z","receivedAt":"2020-03-23T15:09:53Z","isPatch":false,"sender":{"key":"benjamin.shropshire@economicmodeling.com","avatar":null},"body":"$ git --version\ngit version 2.20.1\n\nOn Sun, Mar 22, 2020 at 6:11 PM brian m. carlson\n<sandals@crustytoothpaste.net> wrote:\n>\n> On 2020-03-17 at 18:34:09, Benjamin Shropshire wrote:\n> > From my perspective, this is a bug.\n> >\n> > If I clone a repo twice like this:\n> >\n> > git clone https://github.com/user/repo.git ./https\n> > git clone git@github.com:user/repo.git ./ssh\n> >\n> > And if it contains a .gitmodules like this:\n> >\n> > [submodule \"x\"]\n> >     path = xxx\n> >     url = ../../different-user/something.git\n> >\n> > When I `git submodule update --init --recursive` in each, only the\n> > HTTPS version works. the SSH version confusingly seems to try to find\n> > something at ~/different-user/something.git or some other path in the\n> > local file system.\n>\n> What version of Git are you using?  This works fine for me on a recent\n> next.  In addition, I see we have tests for this in t0060, and adding an\n> additional case for this appears to pass.\n> --\n> brian m. carlson: Houston, Texas, US\n> OpenPGP: https://keybase.io/bk2204\n"},{"id":"393840","messageId":"20200323235358.GF6499@camp.crustytoothpaste.net","threadId":"53013","inReplyTo":"CAAjm7GZXNXcGMp7p2f+UoDUWMPY+Z4aFHv35tynteVSKDf2Fqw@mail.gmail.com","subject":"Re: Relative url values in .gitmodules confusingly sensitive to clone via ssh vs https.","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2020-03-23T23:53:58Z","receivedAt":"2020-03-23T23:54:06Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2020-03-23 at 15:09:39, Benjamin Shropshire wrote:\n> $ git --version\n> git version 2.20.1\n\nHmmm, it looks like that version has the same test, t0060, which has\nthis:\n\n  test_submodule_relative_url \"(null)\" \"user@host:path/to/repo\" \"../subrepo\" \"user@host:path/to/subrepo\"\n  test_submodule_relative_url \"(null)\" \"user@host:repo\" \"../subrepo\" \"user@host:subrepo\"\n  test_submodule_relative_url \"(null)\" \"user@host:repo\" \"../../subrepo\" \".:subrepo\"\n\nI have confirmed that your test case does work for me on the version of\nGit I mentioned above with the following repos:\n\n  bmc@castro:foo/foo.git\n  bmc@castro:bar/bar.git\n\nAnd foo.git having the following .gitmodules:\n\n  [submodule \"bar.git\"]\n          path = bar.git\n          url = ../../bar/bar.git\n\nIt's puzzling to me that this isn't working for you on 2.20.1 but it\nworks for me on a 2.26 prerelease, yet both versions have the same test.\n-- \nbrian m. carlson: Houston, Texas, US\nOpenPGP: https://keybase.io/bk2204\n"}]}