Re: git 2.3.4, ssh: Could not resolve hostname

From: Torsten Bögershausen <tboegi@web.de>
Date: Apr 3, 2015, 00:02 UTC
Message-ID: <551DD887.2010403@web.de>
In-Reply-To: <20150402193524.GA21555@peff.net>

On 2015-04-02 21.35, Jeff King wrote:

Show 20 quoted lines

> 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
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, (because the OS doesn't seem to do so):

./git clone git://git.kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git Cloning into 'v4l-dvb'... fatal: unable to connect to git.kernel.org:: git.kernel.org:[0: 62.157.140.133]: errno=Connection refused git.kernel.org:[1: 80.156.86.78]: errno=Connection refused

(Especially the "::" is a little bit funny: the first ':' is the extra one, the second one comes from the error message: "unable to connect to %s:\n%s"

That is not really user-friendly, so I put it onto my TODO-list
It seems as if it comes from the repair of another regression, which re-allows
the usage of IPV6 addresses without []:
./git fetch-pack  --diag-url  ssh://::1/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git
Diag: url=ssh://::1/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git
Diag: protocol=ssh
Diag: userandhost=::1
Diag: port=NONE
Diag: path=/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git

And this makes sense too:
./git fetch-pack  --diag-url  ssh://git.kernel.org:1/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git
Diag: url=ssh://git.kernel.org:1/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git
Diag: protocol=ssh
Diag: userandhost=git.kernel.org
Diag: port=1
Diag: path=/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git

But not this one:
 ./git fetch-pack  --diag-url  ssh://git.kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git
Diag: url=ssh://git.kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git
Diag: protocol=ssh
Diag: userandhost=git.kernel.org:
Diag: port=NONE

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 ?