{"thread":{"id":"38980","subject":"git 2.3.4, ssh: Could not resolve hostname","startedAt":"2015-04-02T17:18:33Z","lastAt":"2015-04-04T07:21:44Z","messageCount":16,"participants":["Reid Woodbury Jr.","Jeff King","Junio C Hamano","Thomas Schneider","Torsten Bögershausen","brian m. carlson","Kyle J. McKay"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"258866","messageId":"56B33978-76A0-4EE0-BCC0-EF030FD52E41@rawsound.com","threadId":"38980","inReplyTo":null,"subject":"git 2.3.4, ssh: Could not resolve hostname","fromName":"Reid Woodbury Jr.","fromEmail":"reidw@rawsound.com","sentAt":"2015-04-02T17:18:33Z","receivedAt":"2015-04-02T17:18:33Z","isPatch":false,"sender":{"key":"reidw@rawsound.com","avatar":"https://gravatar.com/avatar/de18a4570030c27e1456012a27601a42e8ffdb7fbc6cdc54acfd779ff6289263?d=mp&s=160"},"body":"Dear Sirs\n\nAfter upgrading from GIT 2.3.3 to 2.3.4 (on Mac OS X 10.10.2, installed with MacPorts) I received this error message when doing a push:\n\n$ git push\nssh: Could not resolve hostname xxxx:: nodename nor servname provided, or not known\nfatal: Could not read from remote repository.\n\n\nIt was working previously and nothing in ~/.gitconfig nor .git/config was changed. I rolled back to 2.3.3 and it is working again.\n\nReid Woodbury\nhttps://github.com/diskerror"},{"id":"258870","messageId":"20150402180914.GA19081@peff.net","threadId":"38980","inReplyTo":"56B33978-76A0-4EE0-BCC0-EF030FD52E41@rawsound.com","subject":"Re: git 2.3.4, ssh: Could not resolve hostname","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-04-02T18:09:15Z","receivedAt":"2015-04-02T18:09:15Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Apr 02, 2015 at 10:18:33AM -0700, Reid Woodbury Jr. wrote:\n\n> After upgrading from GIT 2.3.3 to 2.3.4 (on Mac OS X 10.10.2,\n> installed with MacPorts) I received this error message when doing a\n> push:\n> \n> $ git push\n> ssh: Could not resolve hostname xxxx:: nodename nor servname provided, or not known\n> fatal: Could not read from remote repository.\n\nIt is hard to tell from the obfuscated output, but perhaps the problem\nis the two colons (i.e., git is feeding a hostname like \"foo:\" when it\nshould be just \"foo\"). There were some changes in v2.3.4 related to\nparsing ssh URLs. +cc Torsten, who worked on that code.\n\nCan you show us your git config (presumably the host is defined in\nremote.origin.url in .git/config of the repository)?\n\n-Peff\n"},{"id":"258873","messageId":"201C57EF-FC96-4FFB-81D2-90F94428A6CA@rawsound.com","threadId":"38980","inReplyTo":"20150402180914.GA19081@peff.net","subject":"Re: git 2.3.4, ssh: Could not resolve hostname","fromName":"Reid Woodbury Jr.","fromEmail":"reidw@rawsound.com","sentAt":"2015-04-02T18:58:13Z","receivedAt":"2015-04-02T18:58:13Z","isPatch":false,"sender":{"key":"reidw@rawsound.com","avatar":"https://gravatar.com/avatar/de18a4570030c27e1456012a27601a42e8ffdb7fbc6cdc54acfd779ff6289263?d=mp&s=160"},"body":"Peff\nThe colons were part of the output. The 'xxxx' replaces the domain in the response. The domain is an internal one that my client would rather keep private. But this got me to think that this might be an important detail: I am using GIT from a remote node on a Cisco AnyConnect VPN with DNS served by ActiveDirectory.\nReid\n\n\n> On Apr 2, 2015, at 11:09 AM, Jeff King wrote:\n> \n> On Thu, Apr 02, 2015 at 10:18:33AM -0700, Reid Woodbury Jr. wrote:\n> \n>> After upgrading from GIT 2.3.3 to 2.3.4 (on Mac OS X 10.10.2,\n>> installed with MacPorts) I received this error message when doing a\n>> push:\n>> \n>> $ git push\n>> ssh: Could not resolve hostname xxxx:: nodename nor servname provided, or not known\n>> fatal: Could not read from remote repository.\n> \n> It is hard to tell from the obfuscated output, but perhaps the problem\n> is the two colons (i.e., git is feeding a hostname like \"foo:\" when it\n> should be just \"foo\"). There were some changes in v2.3.4 related to\n> parsing ssh URLs. +cc Torsten, who worked on that code.\n> \n> Can you show us your git config (presumably the host is defined in\n> remote.origin.url in .git/config of the repository)?\n> \n> -Peff\n"},{"id":"258876","messageId":"20150402191452.GA20420@peff.net","threadId":"38980","inReplyTo":"201C57EF-FC96-4FFB-81D2-90F94428A6CA@rawsound.com","subject":"Re: git 2.3.4, ssh: Could not resolve hostname","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-04-02T19:14:52Z","receivedAt":"2015-04-02T19:14:52Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Apr 02, 2015 at 11:58:13AM -0700, Reid Woodbury Jr. wrote:\n\n> The colons were part of the output. The 'xxxx' replaces the domain in\n> the response.\n\nOK, if the double colons are correct, then that is almost certainly the\nproblem:\n\n $ ssh does-not-exist\n ssh: Could not resolve hostname does-not-exist: No address associated with hostname\n $ ssh does-not-exist:\n ssh: Could not resolve hostname does-not-exist:: No address associated with hostname\n\n> The domain is an internal one that my client would rather keep private.\n\nCan you give us a hint as to the format of your remote URL? This \"works\":\n\n $ git push does-not-exist:repo.git\n ssh: Could not resolve hostname does-not-exist: No address associated with hostname\n\nin the sense that it looks up the right hostname (which is of course\nnonsense, but note the single colon in the error message). So does:\n\n $ git push ssh://does-not-exist/repo.git\n ssh: Could not resolve hostname does-not-exist: No address associated with hostname\n\nbut this does not:\n\n $ git push ssh://does-not-exist:/repo.git\n ssh: Could not resolve hostname does-not-exist:: No address associated with hostname\n\n(note the doubled colon). v2.3.3 did strip off that extra colon, but I\nam not sure the URL above (i.e., a colon with no hostname) is actually\nsane. IOW, it may have happened to work in older versions, but I'm not\nsure we would want to promise to keep it working.\n\nCan you show us what your URL looks like, obfuscating the names but\nkeeping the syntax the same? Also, are you using the \"insteadOf\" config\nsyntax at all (which could easily lead to funny splicing, I imagine).\n\n> But this got me to think that this might be an\n> important detail: I am using GIT from a remote node on a Cisco\n> AnyConnect VPN with DNS served by ActiveDirectory.\n\nIf the extra colon is indeed the problem, I don't think the DNS setup is\nrelevant. The name git is feeding to ssh is bogus.\n\n-Peff\n"},{"id":"258877","messageId":"xmqq7ftujpu1.fsf@gitster.dls.corp.google.com","threadId":"38980","inReplyTo":"20150402191452.GA20420@peff.net","subject":"Re: git 2.3.4, ssh: Could not resolve hostname","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-04-02T19:24:38Z","receivedAt":"2015-04-02T19:24:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> but this does not:\n>\n> $ git push ssh://does-not-exist:/repo.git\n> ssh: Could not resolve hostname does-not-exist:: No address associated with hostname\n>\n> (note the doubled colon). v2.3.3 did strip off that extra colon, but I\n> am not sure the URL above (i.e., a colon with no hostname) is actually\n> sane. IOW, it may have happened to work in older versions, but I'm not\n> sure we would want to promise to keep it working.\n>\n> Can you show us what your URL looks like, obfuscating the names but\n> keeping the syntax the same? Also, are you using the \"insteadOf\" config\n> syntax at all (which could easily lead to funny splicing, I imagine).\n\nEverything Jeff said ;-)\n\nDepending on the nature of 'xxxx' in the original, Torsten's\nresponse may be different. 'xxxx' could stand for [9999:9999::9999],\na.host.in.domain.xz, 127.0.0.1, or all the other things and it is a\nbit too vague to help us tell which codepath will pick up what and\npossibly screw it up.\n"},{"id":"258878","messageId":"62968860-FA58-4339-AF0B-264197EC8A04@rawsound.com","threadId":"38980","inReplyTo":"xmqq7ftujpu1.fsf@gitster.dls.corp.google.com","subject":"Re: git 2.3.4, ssh: Could not resolve hostname","fromName":"Reid Woodbury Jr.","fromEmail":"reidw@rawsound.com","sentAt":"2015-04-02T19:31:14Z","receivedAt":"2015-04-02T19:31:14Z","isPatch":false,"sender":{"key":"reidw@rawsound.com","avatar":"https://gravatar.com/avatar/de18a4570030c27e1456012a27601a42e8ffdb7fbc6cdc54acfd779ff6289263?d=mp&s=160"},"body":"Ah, understand. Here's my project URL for 'remote \"origin\"' with a more meaningful representation of their internal FQDN:\n\n\turl = ssh://rwoodbury@systemname.groupname.online:/opt/git/inventory.git\n\nThe \"online\" is their literal internal TLD.\n\nReid\n\n> On Apr 2, 2015, at 12:24 PM, Junio C Hamano wrote:\n> \n> Jeff King writes:\n> \n>> but this does not:\n>> \n>> $ git push ssh://does-not-exist:/repo.git\n>> ssh: Could not resolve hostname does-not-exist:: No address associated with hostname\n>> \n>> (note the doubled colon). v2.3.3 did strip off that extra colon, but I\n>> am not sure the URL above (i.e., a colon with no hostname) is actually\n>> sane. IOW, it may have happened to work in older versions, but I'm not\n>> sure we would want to promise to keep it working.\n>> \n>> Can you show us what your URL looks like, obfuscating the names but\n>> keeping the syntax the same? Also, are you using the \"insteadOf\" config\n>> syntax at all (which could easily lead to funny splicing, I imagine).\n> \n> Everything Jeff said ;-)\n> \n> Depending on the nature of 'xxxx' in the original, Torsten's\n> response may be different. 'xxxx' could stand for [9999:9999::9999],\n> a.host.in.domain.xz, 127.0.0.1, or all the other things and it is a\n> bit too vague to help us tell which codepath will pick up what and\n> possibly screw it up.\n> \n"},{"id":"258880","messageId":"20150402193524.GA21555@peff.net","threadId":"38980","inReplyTo":"62968860-FA58-4339-AF0B-264197EC8A04@rawsound.com","subject":"Re: git 2.3.4, ssh: Could not resolve hostname","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-04-02T19:35:24Z","receivedAt":"2015-04-02T19:35:24Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Apr 02, 2015 at 12:31:14PM -0700, Reid Woodbury Jr. wrote:\n\n> Ah, understand. Here's my project URL for 'remote \"origin\"' with a\n> more meaningful representation of their internal FQDN:\n> \n> \turl = ssh://rwoodbury@systemname.groupname.online:/opt/git/inventory.git\n> \n> The \"online\" is their literal internal TLD.\n\nThanks. The problem is the extra \":\" after \"online\"; your URL is\nmalformed. You can just drop that colon entirely.\n\nI do not think we need to support this syntax going forward (the colon\nis meaningless here, and our documentation is clear that it should go\nwith a port number), but on the other hand, it might be nice to be more\nliberal, as we were in v2.3.3 and prior. I'll leave it to Torsten to see\nwhether supporting that would hurt some of the other cases, or whether\nit would make the code too awkward.\n\n-Peff\n"},{"id":"258882","messageId":"5B043A67-E2FC-4F40-89C5-915B3D893459@rawsound.com","threadId":"38980","inReplyTo":"20150402193524.GA21555@peff.net","subject":"Re: git 2.3.4, ssh: Could not resolve hostname","fromName":"Reid Woodbury Jr.","fromEmail":"reidw@rawsound.com","sentAt":"2015-04-02T20:06:00Z","receivedAt":"2015-04-02T20:06:00Z","isPatch":false,"sender":{"key":"reidw@rawsound.com","avatar":"https://gravatar.com/avatar/de18a4570030c27e1456012a27601a42e8ffdb7fbc6cdc54acfd779ff6289263?d=mp&s=160"},"body":"Yup, removing the colon works in both 2.3.3 and 2.3.4. And I see that the manual doesn't use the colon! (eg. $ git clone ssh://user@server/project.git). The usage of the colon looks normal to my eyes because, for instance, SFTP uses it to set the path on login so this wasn't something I would have even considered. I'm sure I've seen it other places but I can't remember right now.\n\nThanks all for your time.\n\n\n> On Apr 2, 2015, at 12:35 PM, Jeff King wrote:\n> \n> On Thu, Apr 02, 2015 at 12:31:14PM -0700, Reid Woodbury Jr. wrote:\n> \n>> Ah, understand. Here's my project URL for 'remote \"origin\"' with a\n>> more meaningful representation of their internal FQDN:\n>> \n>> \turl = ssh://rwoodbury@systemname.groupname.online:/opt/git/inventory.git\n>> \n>> The \"online\" is their literal internal TLD.\n> \n> Thanks. The problem is the extra \":\" after \"online\"; your URL is\n> malformed. You can just drop that colon entirely.\n> \n> I do not think we need to support this syntax going forward (the colon\n> is meaningless here, and our documentation is clear that it should go\n> with a port number), but on the other hand, it might be nice to be more\n> liberal, as we were in v2.3.3 and prior. I'll leave it to Torsten to see\n> whether supporting that would hurt some of the other cases, or whether\n> it would make the code too awkward.\n> \n> -Peff\n"},{"id":"258883","messageId":"CAJUTLVV_6ezYKQA2-hM2nLGedVA1n1WED1mojaPymvUPb7F_Jg@mail.gmail.com","threadId":"38980","inReplyTo":"5B043A67-E2FC-4F40-89C5-915B3D893459@rawsound.com","subject":"Re: git 2.3.4, ssh: Could not resolve hostname","fromName":"Thomas Schneider","fromEmail":"thosch97@gmail.com","sentAt":"2015-04-02T20:15:30Z","receivedAt":"2015-04-02T20:15:30Z","isPatch":false,"sender":{"key":"thosch97@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1690172?v=4"},"body":"2015-04-02 22:06 GMT+02:00 Reid Woodbury Jr. :\n> I'm sure I've seen it other places but I can't remember right now.\nWhat you mean is the scp-like syntax: user@host:path/relative/to/home\n– but if you write user@host:/path/to/something, it’s relative to /.\nYou can also achieve paths relative to the home directory with the\nother syntax: ssh://user@host/~/path/relative/to/home.\n"},{"id":"258910","messageId":"551DD887.2010403@web.de","threadId":"38980","inReplyTo":"20150402193524.GA21555@peff.net","subject":"Re: git 2.3.4, ssh: Could not resolve hostname","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2015-04-03T00:02:15Z","receivedAt":"2015-04-03T00:02:15Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On 2015-04-02 21.35, Jeff King wrote:\n> On Thu, Apr 02, 2015 at 12:31:14PM -0700, Reid Woodbury Jr. wrote:\n> \n>> Ah, understand. Here's my project URL for 'remote \"origin\"' with a\n>> more meaningful representation of their internal FQDN:\n>>\n>> \turl = ssh://rwoodbury@systemname.groupname.online:/opt/git/inventory.git\n>>\n>> The \"online\" is their literal internal TLD.\n> \n> Thanks. The problem is the extra \":\" after \"online\"; your URL is\n> malformed. You can just drop that colon entirely.\n> \n> I do not think we need to support this syntax going forward (the colon\n> is meaningless here, and our documentation is clear that it should go\n> with a port number), but on the other hand, it might be nice to be more\n> liberal, as we were in v2.3.3 and prior. I'll leave it to Torsten to see\n> whether supporting that would hurt some of the other cases, or whether\n> it would make the code too awkward.\n> \n> -Peff\n\nThanks for digging.\n\nThis makes my think that it is\na) non-standard to have the extra colon\nb) The error message could be better\nc) We don't have a test case\nd) This reminds my of an improvement from Linus:\n608d48b2207a61528\n......\n So when somebody passes me a \"please pull\" request pointing to something\n like the following\n \n \tgit://git.kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git\n \n (note the extraneous colon at the end of the host name), git would happily\n try to connect to port 0, which would generally just cause the remote to\n not even answer, and the \"connect()\" will take a long time to time out.\n.....\n\nSorry guys for the regression, the old parser handled the extra colon as \"port 0\",\nthe new one looks for the \"/\" as the end of the hostname (and the beginning of the path) \n\nEither we accept the extra colon as before, or the parser puts out a better error message,\n(because the OS doesn't seem to do so):\n\n./git clone git://git.kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git\nCloning into 'v4l-dvb'...\nfatal: unable to connect to git.kernel.org::\ngit.kernel.org:[0: 62.157.140.133]: errno=Connection refused\ngit.kernel.org:[1: 80.156.86.78]: errno=Connection refused\n\n(Especially the \"::\" is a little bit funny: the first ':' is the extra one,\nthe second one comes from the error message:\n\"unable to connect to %s:\\n%s\"\n\nThat is not really user-friendly, so I put it onto my TODO-list\nIt seems as if it comes from the repair of another regression, which re-allows\nthe usage of IPV6 addresses without []:\n./git fetch-pack --diag-url ssh://::1/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git\nDiag: url=ssh://::1/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git\nDiag: protocol=ssh\nDiag: userandhost=::1\nDiag: port=NONE\nDiag: path=/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git\n\n\nAnd this makes sense too:\n./git fetch-pack --diag-url ssh://git.kernel.org:1/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git\nDiag: url=ssh://git.kernel.org:1/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git\nDiag: protocol=ssh\nDiag: userandhost=git.kernel.org\nDiag: port=1\nDiag: path=/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git\n\n\nBut not this one:\n ./git fetch-pack --diag-url ssh://git.kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git\nDiag: url=ssh://git.kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git\nDiag: protocol=ssh\nDiag: userandhost=git.kernel.org:\nDiag: port=NONE\n\n\nSpontaneously I would say that a trailing ':' at the end of a hostname in the ssh:// scheme\ncan be safely ignored, what do you think ?\n"},{"id":"258915","messageId":"20150403013021.GA10125@vauxhall.crustytoothpaste.net","threadId":"38980","inReplyTo":"551DD887.2010403@web.de","subject":"Re: git 2.3.4, ssh: Could not resolve hostname","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2015-04-03T01:30:21Z","receivedAt":"2015-04-03T01:30:21Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Fri, Apr 03, 2015 at 02:02:15AM +0200, Torsten Bögershausen wrote:\n> But not this one:\n> ./git fetch-pack --diag-url ssh://git.kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git\n> Diag: url=ssh://git.kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git\n> Diag: protocol=ssh\n> Diag: userandhost=git.kernel.org:\n> Diag: port=NONE\n> \n> \n> Spontaneously I would say that a trailing ':' at the end of a hostname in the ssh:// scheme\n> can be safely ignored, what do you think ?\n\nI think instead of ignoring it we can just produce an error. The user\nmight have meant to specify a port, but forgotten. I've done similar\nthings before.\n\nI generally prefer being a bit stricter and giving helpful error\nmessages rather than trying to intuit what the user meant. The user is\nalways going to come up with a new way to break the code.\n-- \nbrian m. carlson / brian with sandals: Houston, Texas, US\n+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only\nOpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187\n"},{"id":"258941","messageId":"xmqqy4m9exj0.fsf@gitster.dls.corp.google.com","threadId":"38980","inReplyTo":"551DD887.2010403@web.de","subject":"Re: git 2.3.4, ssh: Could not resolve hostname","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-04-03T21:01:55Z","receivedAt":"2015-04-03T21:01:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Torsten Bögershausen writes:\n\n> This makes my think that it is\n> a) non-standard to have the extra colon\n> b) The error message could be better\n\nFor that, perhaps\n\n-ssh: Could not resolve hostname xxxx:: nodename nor servname provided, or not known\n+ssh: Could not resolve hostname \"xxxx:\": nodename nor servname provided, or not known\n\nwould be something we would want to do, no matter what other fixes\nwe would apply.\n\n> Spontaneously I would say that a trailing ':' at the end of a\n> hostname in the ssh:// scheme can be safely ignored, what do you\n> think?\n\nIf it is not too much hassle to make the current code do so, I'd say\nthat is a good way forward. Giving a warning that lets the user\nknow that the input has an extra and unwanted colon in it may be a\nplus, too.\n\nThanks.\n"},{"id":"258942","messageId":"20150403210547.GA10380@peff.net","threadId":"38980","inReplyTo":"xmqqy4m9exj0.fsf@gitster.dls.corp.google.com","subject":"Re: git 2.3.4, ssh: Could not resolve hostname","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-04-03T21:05:47Z","receivedAt":"2015-04-03T21:05:47Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Apr 03, 2015 at 02:01:55PM -0700, Junio C Hamano wrote:\n\n> Torsten Bögershausen writes:\n> \n> > This makes my think that it is\n> > a) non-standard to have the extra colon\n> > b) The error message could be better\n> \n> For that, perhaps\n> \n> -ssh: Could not resolve hostname xxxx:: nodename nor servname provided, or not known\n> +ssh: Could not resolve hostname \"xxxx:\": nodename nor servname provided, or not known\n> \n> would be something we would want to do, no matter what other fixes\n> we would apply.\n\nThat message comes from the ssh client. So the \"we\" here would have to submit a\npatch to OpenSSH\".\n\nThe easier way to diagnose inside git is to set GIT_TRACE, which makes\nit more clear:\n\n $ GIT_TRACE=1 git clone ssh://bogosity:/repo.git\n ...\n 17:05:00.734019 run-command.c:347 trace: run_command: 'ssh' 'bogosity:' 'git-upload-pack '\\''/repo.git'\\'''\n\n-Peff\n"},{"id":"258948","messageId":"51689E6C-93FD-4E77-8FF3-BB8EC7EA735A@gmail.com","threadId":"38980","inReplyTo":"551DD887.2010403@web.de","subject":"Re: git 2.3.4, ssh: Could not resolve hostname","fromName":"Kyle J. McKay","fromEmail":"mackyle@gmail.com","sentAt":"2015-04-03T21:32:24Z","receivedAt":"2015-04-03T21:32:24Z","isPatch":false,"sender":{"key":"mackyle@gmail.com","avatar":"https://avatars.githubusercontent.com/u/813346?v=4"},"body":"On Apr 2, 2015, at 17:02, Torsten Bögershausen wrote:\n\n> On 2015-04-02 21.35, Jeff King wrote:\n>> On Thu, Apr 02, 2015 at 12:31:14PM -0700, Reid Woodbury Jr. wrote:\n>>\n>>> Ah, understand. Here's my project URL for 'remote \"origin\"' with a\n>>> more meaningful representation of their internal FQDN:\n>>>\n>>> \turl = ssh://rwoodbury@systemname.groupname.online:/opt/git/inventory.git\n>>>\n>>> The \"online\" is their literal internal TLD.\n>>\n>> Thanks. The problem is the extra \":\" after \"online\"; your URL is\n>> malformed. You can just drop that colon entirely.\n>>\n>> I do not think we need to support this syntax going forward (the \n>> colon\n>> is meaningless here, and our documentation is clear that it should go\n>> with a port number), but on the other hand, it might be nice to be \n>> more\n>> liberal, as we were in v2.3.3 and prior. I'll leave it to Torsten \n>> to see\n>> whether supporting that would hurt some of the other cases, or \n>> whether\n>> it would make the code too awkward.\n>>\n>> -Peff\n>\n> Thanks for digging.\n>\n> This makes my think that it is\n> a) non-standard to have the extra colon\n\nIt's not. See RFC 3986 appendix A:\n\n authority = [ userinfo \"@\" ] host [ \":\" port ]\n\n port = *DIGIT\n\n\"*DIGIT\" means (see RFC 2234 section 3.6) zero or more digits.\n\n> b) The error message could be better\n> c) We don't have a test case\n> d) This reminds my of an improvement from Linus:\n> 608d48b2207a61528\n> ......\n> So when somebody passes me a \"please pull\" request pointing to \n> something\n> like the following\n>\n> \tgit://git.kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git\n>\n> (note the extraneous colon at the end of the host name), git \n> would happily\n> try to connect to port 0, which would generally just cause the \n> remote to\n> not even answer, and the \"connect()\" will take a long time to \n> time out.\n> .....\n>\n> Sorry guys for the regression, the old parser handled the extra \n> colon as \"port 0\",\n> the new one looks for the \"/\" as the end of the hostname (and the \n> beginning of the path)\n>\n> Either we accept the extra colon as before, or the parser puts out a \n> better error message,\n\n[...]\n\n> Spontaneously I would say that a trailing ':' at the end of a \n> hostname in the ssh:// scheme\n> can be safely ignored, what do you think ?\n\nYou know, there is a \"url_normalize\" routine in urlmatch.h/urlmatch.c \nthat checks for a lot of these things and provides a translated error \nmessage if there's a problem as well as normalizing and separating out \nthe various parts of the URL. It does not currently handle default \nports for anything other than http[s] but it would be simple enough to \nadd support for ssh, git, ftp[s] and rsync default ports too.\n\n-Kyle"},{"id":"258966","messageId":"701694C7-311A-4625-A871-48D5F04EB0F9@rawsound.com","threadId":"38980","inReplyTo":"51689E6C-93FD-4E77-8FF3-BB8EC7EA735A@gmail.com","subject":"Re: git 2.3.4, ssh: Could not resolve hostname","fromName":"Reid Woodbury Jr.","fromEmail":"reidw@rawsound.com","sentAt":"2015-04-04T00:19:21Z","receivedAt":"2015-04-04T00:19:21Z","isPatch":false,"sender":{"key":"reidw@rawsound.com","avatar":"https://gravatar.com/avatar/de18a4570030c27e1456012a27601a42e8ffdb7fbc6cdc54acfd779ff6289263?d=mp&s=160"},"body":"Thanks for keeping me in the loop!\n\nI have two thoughts on handling input:\n\nAs a coder I want to know exactly what's going on in my code. If I've given erroneous input I'd like to know about it in the most useful and quickest way, never glossed over, liberally accepted, nor fixed for me even if the input is non-ambigous. I won't learn the right way unless I'm told. I enjoy that when I've typo'd a command in GIT it gives useful suggestions to what I might have meant.\n\nBut, most of the coding *I* do is for the non-coder or the general end user. These might be people that would reasonably yell at their computer screen \"you know what I meant!\" So I try to be more liberal in the input I write code to accept by filtering it, cleaning it, etc. I'll even filter input by keystroke when possible. I have the philosophy: don't tell the user that they input something bad, just prevent them from inputting it to begin with. I know, this is appropriate when building a GUI and not for CLI.\n\nthanks for listening\nReid Woodbury\n\n\n> On Apr 3, 2015, at 2:32 PM, Kyle J. McKay wrote:\n> \n> On Apr 2, 2015, at 17:02, Torsten Bögershausen wrote:\n> \n>> On 2015-04-02 21.35, Jeff King wrote:\n>>> On Thu, Apr 02, 2015 at 12:31:14PM -0700, Reid Woodbury Jr. wrote:\n>>> \n>>>> Ah, understand. Here's my project URL for 'remote \"origin\"' with a\n>>>> more meaningful representation of their internal FQDN:\n>>>> \n>>>> \turl = ssh://rwoodbury@systemname.groupname.online:/opt/git/inventory.git\n>>>> \n>>>> The \"online\" is their literal internal TLD.\n>>> \n>>> Thanks. The problem is the extra \":\" after \"online\"; your URL is\n>>> malformed. You can just drop that colon entirely.\n>>> \n>>> I do not think we need to support this syntax going forward (the colon\n>>> is meaningless here, and our documentation is clear that it should go\n>>> with a port number), but on the other hand, it might be nice to be more\n>>> liberal, as we were in v2.3.3 and prior. I'll leave it to Torsten to see\n>>> whether supporting that would hurt some of the other cases, or whether\n>>> it would make the code too awkward.\n>>> \n>>> -Peff\n>> \n>> Thanks for digging.\n>> \n>> This makes my think that it is\n>> a) non-standard to have the extra colon\n> \n> It's not. See RFC 3986 appendix A:\n> \n> authority = [ userinfo \"@\" ] host [ \":\" port ]\n> \n> port = *DIGIT\n> \n> \"*DIGIT\" means (see RFC 2234 section 3.6) zero or more digits.\n> \n>> b) The error message could be better\n>> c) We don't have a test case\n>> d) This reminds my of an improvement from Linus:\n>> 608d48b2207a61528\n>> ......\n>> So when somebody passes me a \"please pull\" request pointing to something\n>> like the following\n>> \n>> \tgit://git.kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git\n>> \n>> (note the extraneous colon at the end of the host name), git would happily\n>> try to connect to port 0, which would generally just cause the remote to\n>> not even answer, and the \"connect()\" will take a long time to time out.\n>> .....\n>> \n>> Sorry guys for the regression, the old parser handled the extra colon as \"port 0\",\n>> the new one looks for the \"/\" as the end of the hostname (and the beginning of the path)\n>> \n>> Either we accept the extra colon as before, or the parser puts out a better error message,\n> \n> [...]\n> \n>> Spontaneously I would say that a trailing ':' at the end of a hostname in the ssh:// scheme\n>> can be safely ignored, what do you think ?\n> \n> You know, there is a \"url_normalize\" routine in urlmatch.h/urlmatch.c that checks for a lot of these things and provides a translated error message if there's a problem as well as normalizing and separating out the various parts of the URL. It does not currently handle default ports for anything other than http[s] but it would be simple enough to add support for ssh, git, ftp[s] and rsync default ports too.\n> \n> -Kyle\n"},{"id":"258983","messageId":"551F9108.6090301@web.de","threadId":"38980","inReplyTo":"701694C7-311A-4625-A871-48D5F04EB0F9@rawsound.com","subject":"Re: git 2.3.4, ssh: Could not resolve hostname","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2015-04-04T07:21:44Z","receivedAt":"2015-04-04T07:21:44Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On 2015-04-04 02.19, Reid Woodbury Jr. wrote:\n> Thanks for keeping me in the loop!\n> \n> I have two thoughts on handling input:\n> \n> As a coder I want to know exactly what's going on in my code. If I've given erroneous input I'd like to know about it in the most useful and quickest way, never glossed over, liberally accepted, nor fixed for me even if the input is non-ambigous. I won't learn the right way unless I'm told. I enjoy that when I've typo'd a command in GIT it gives useful suggestions to what I might have meant.\n> \n> But, most of the coding *I* do is for the non-coder or the general end user. These might be people that would reasonably yell at their computer screen \"you know what I meant!\" So I try to be more liberal in the input I write code to accept by filtering it, cleaning it, etc. I'll even filter input by keystroke when possible. I have the philosophy: don't tell the user that they input something bad, just prevent them from inputting it to begin with. I know, this is appropriate when building a GUI and not for CLI.\n> \n> thanks for listening\n> Reid Woodbury\n> \nThanks for the report.\n(And please try to avoid top-posting to this list in the future ;-)\n\nThe basic fix will look like below, but I need to update the test-suite as well.\n\n\ndiff --git a/connect.c b/connect.c\nindex ce0e121..c8744f3 100644\n--- a/connect.c\n+++ b/connect.c\n@@ -310,6 +310,8 @@ static void get_host_and_port(char **host, const char **port)\n if (end != colon + 1 && *end == '\\0' && 0 <= portnr && portnr < 65536) {\n *colon = 0;\n *port = colon + 1;\n+ } else if (!colon[1]) {\n+ *colon = 0;\n }\n }\n }\n@@ -385,7 +387,7 @@ static int git_tcp_connect_sock(char *host, int flags)\n freeaddrinfo(ai0);\n \n if (sockfd < 0)\n- die(\"unable to connect to %s:\\n%s\", host, error_message.buf);\n+ die(\"unable to connect to '%s' :\\n%s\", host, error_message.buf);\n \n enable_keepalive(sockfd);\n\n> \n>> On Apr 3, 2015, at 2:32 PM, Kyle J. McKay wrote:\n>>\n>> On Apr 2, 2015, at 17:02, Torsten Bögershausen wrote:\n>>\n>>> On 2015-04-02 21.35, Jeff King wrote:\n>>>> On Thu, Apr 02, 2015 at 12:31:14PM -0700, Reid Woodbury Jr. wrote:\n>>>>\n>>>>> Ah, understand. Here's my project URL for 'remote \"origin\"' with a\n>>>>> more meaningful representation of their internal FQDN:\n>>>>>\n>>>>> \turl = ssh://rwoodbury@systemname.groupname.online:/opt/git/inventory.git\n>>>>>\n>>>>> The \"online\" is their literal internal TLD.\n>>>>\n>>>> Thanks. The problem is the extra \":\" after \"online\"; your URL is\n>>>> malformed. You can just drop that colon entirely.\n>>>>\n>>>> I do not think we need to support this syntax going forward (the colon\n>>>> is meaningless here, and our documentation is clear that it should go\n>>>> with a port number), but on the other hand, it might be nice to be more\n>>>> liberal, as we were in v2.3.3 and prior. I'll leave it to Torsten to see\n>>>> whether supporting that would hurt some of the other cases, or whether\n>>>> it would make the code too awkward.\n>>>>\n>>>> -Peff\n>>>\n>>> Thanks for digging.\n>>>\n>>> This makes my think that it is\n>>> a) non-standard to have the extra colon\n>>\n>> It's not. See RFC 3986 appendix A:\n>>\n>> authority = [ userinfo \"@\" ] host [ \":\" port ]\n>>\n>> port = *DIGIT\n>>\n>> \"*DIGIT\" means (see RFC 2234 section 3.6) zero or more digits.\n>>\n>>> b) The error message could be better\n>>> c) We don't have a test case\n>>> d) This reminds my of an improvement from Linus:\n>>> 608d48b2207a61528\n>>> ......\n>>> So when somebody passes me a \"please pull\" request pointing to something\n>>> like the following\n>>>\n>>> \tgit://git.kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git\n>>>\n>>> (note the extraneous colon at the end of the host name), git would happily\n>>> try to connect to port 0, which would generally just cause the remote to\n>>> not even answer, and the \"connect()\" will take a long time to time out.\n>>> .....\n>>>\n>>> Sorry guys for the regression, the old parser handled the extra colon as \"port 0\",\n>>> the new one looks for the \"/\" as the end of the hostname (and the beginning of the path)\n>>>\n>>> Either we accept the extra colon as before, or the parser puts out a better error message,\n>>\n>> [...]\n>>\n>>> Spontaneously I would say that a trailing ':' at the end of a hostname in the ssh:// scheme\n>>> can be safely ignored, what do you think ?\n>>\n>> You know, there is a \"url_normalize\" routine in urlmatch.h/urlmatch.c that checks for a lot of these things and provides a translated error message if there's a problem as well as normalizing and separating out the various parts of the URL. It does not currently handle default ports for anything other than http[s] but it would be simple enough to add support for ssh, git, ftp[s] and rsync default ports too.\n>>\n>> -Kyle\n> \n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n> \n"}]}