Re: git 2.3.4, ssh: Could not resolve hostname
Thanks for keeping me in the loop! I have two thoughts on handling input: 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. 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. thanks for listening Reid Woodbury On Apr 3, 2015, at 2:32 PM, Kyle J. McKay mack...@gmail.com wrote: On Apr 2, 2015, at 17:02, Torsten Bögershausen wrote: On 2015-04-02 21.35, Jeff King wrote: On Thu, Apr 02, 2015 at 12:31:14PM -0700, Reid Woodbury Jr. wrote: Ah, understand. Here's my project URL for 'remote origin' with a more meaningful representation of their internal FQDN: url = ssh://rwoodbury@systemname.groupname.online:/opt/git/inventory.git The online is their literal internal TLD. Thanks. The problem is the extra : after online; your URL is malformed. You can just drop that colon entirely. I do not think we need to support this syntax going forward (the colon is meaningless here, and our documentation is clear that it should go with a port number), but on the other hand, it might be nice to be more liberal, as we were in v2.3.3 and prior. I'll leave it to Torsten to see whether supporting that would hurt some of the other cases, or whether it would make the code too awkward. -Peff Thanks for digging. This makes my think that it is a) non-standard to have the extra colon It's not. See RFC 3986 appendix A: authority = [ userinfo @ ] host [ : port ] port = *DIGIT *DIGIT means (see RFC 2234 section 3.6) zero or more digits. b) The error message could be better c) We don't have a test case d) This reminds my of an improvement from Linus: 608d48b2207a61528 .. So when somebody passes me a please pull request pointing to something like the following git://git.kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git (note the extraneous colon at the end of the host name), git would happily try to connect to port 0, which would generally just cause the remote to not even answer, and the connect() will take a long time to time out. . Sorry guys for the regression, the old parser handled the extra colon as port 0, the new one looks for the / as the end of the hostname (and the beginning of the path) Either we accept the extra colon as before, or the parser puts out a better error message, [...] Spontaneously I would say that a trailing ':' at the end of a hostname in the ssh:// scheme can be safely ignored, what do you think ? 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. -Kyle -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git 2.3.4, ssh: Could not resolve hostname
Ah, understand. Here's my project URL for 'remote origin' with a more meaningful representation of their internal FQDN: url = ssh://rwoodbury@systemname.groupname.online:/opt/git/inventory.git The online is their literal internal TLD. Reid On Apr 2, 2015, at 12:24 PM, Junio C Hamano gits...@pobox.com wrote: Jeff King p...@peff.net writes: but this does not: $ git push ssh://does-not-exist:/repo.git ssh: Could not resolve hostname does-not-exist:: No address associated with hostname (note the doubled colon). v2.3.3 did strip off that extra colon, but I am not sure the URL above (i.e., a colon with no hostname) is actually sane. IOW, it may have happened to work in older versions, but I'm not sure we would want to promise to keep it working. Can you show us what your URL looks like, obfuscating the names but keeping the syntax the same? Also, are you using the insteadOf config syntax at all (which could easily lead to funny splicing, I imagine). Everything Jeff said ;-) Depending on the nature of '' in the original, Torsten's response may be different. '' could stand for [:::], a.host.in.domain.xz, 127.0.0.1, or all the other things and it is a bit too vague to help us tell which codepath will pick up what and possibly screw it up. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git 2.3.4, ssh: Could not resolve hostname
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. Thanks all for your time. On Apr 2, 2015, at 12:35 PM, Jeff King p...@peff.net wrote: On Thu, Apr 02, 2015 at 12:31:14PM -0700, Reid Woodbury Jr. wrote: Ah, understand. Here's my project URL for 'remote origin' with a more meaningful representation of their internal FQDN: url = ssh://rwoodbury@systemname.groupname.online:/opt/git/inventory.git The online is their literal internal TLD. Thanks. The problem is the extra : after online; your URL is malformed. You can just drop that colon entirely. I do not think we need to support this syntax going forward (the colon is meaningless here, and our documentation is clear that it should go with a port number), but on the other hand, it might be nice to be more liberal, as we were in v2.3.3 and prior. I'll leave it to Torsten to see whether supporting that would hurt some of the other cases, or whether it would make the code too awkward. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git 2.3.4, ssh: Could not resolve hostname
Peff The colons were part of the output. The '' 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. Reid On Apr 2, 2015, at 11:09 AM, Jeff King p...@peff.net wrote: On Thu, Apr 02, 2015 at 10:18:33AM -0700, Reid Woodbury Jr. wrote: After 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: $ git push ssh: Could not resolve hostname :: nodename nor servname provided, or not known fatal: Could not read from remote repository. It is hard to tell from the obfuscated output, but perhaps the problem is the two colons (i.e., git is feeding a hostname like foo: when it should be just foo). There were some changes in v2.3.4 related to parsing ssh URLs. +cc Torsten, who worked on that code. Can you show us your git config (presumably the host is defined in remote.origin.url in .git/config of the repository)? -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git 2.3.4, ssh: Could not resolve hostname
Dear Sirs After 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: $ git push ssh: Could not resolve hostname :: nodename nor servname provided, or not known fatal: Could not read from remote repository. It was working previously and nothing in ~/.gitconfig nor .git/config was changed. I rolled back to 2.3.3 and it is working again. Reid Woodbury https://github.com/diskerror-- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
