Torsten Bögershausen <tbo...@web.de> 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? -- 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
