From: Junio C Hamano Date: Mon, 23 May 2016 21:30:57 GMT Subject: Re: [PATCH v7 1/9] connect: document why we sometimes call get_port after get_host_and_port Message-ID: In-Reply-To: <574287B9.4090307@web.de> Torsten Bögershausen writes: >>>> get_host_and_port(&ssh_host, &port); >>>> + /* get_host_and_port may not return a port >>>> even when >>>> + * there is one: In the [host:port]:path case, >>>> + * get_host_and_port is called with "[host:port]" and >>>> + * returns "host:port" and NULL. >>>> + * In that specific case, we still need to split the >>>> + * port. */ >>> Is it worth to mention that this case is "still supported legacy" ? >> If it's worth mentioning anywhere, it seems to me it would start with >> urls.txt? >> >> Mike >> > I don't know. > urls.txt is for Git users, and connect.c is for Git developers. > urls.txt does not mention that Git follows any RFC when parsing the > URLS', it doesn't claim to be 100% compliant. > Even if it makes sense to do so, as many user simply expect Git to accept > RFC compliant URL's, and it makes the development easier, if there is > an already > written specification, that describes all the details. > The parser is not 100% RFC compliant, one example: > - old-style usgage like "git clone [host:222]:~/path/to/repo are supported Is it an option to fix get_host_and_port() so that it returns what the caller expects even when it is given "[host:port]"? When the caller passes other forms like "host:port", it expects to get "host" and "port" parsed out into two variables. Why can't the caller expect to see the same happen when feeding "[host:port]" to the function?