On Mon, May 23, 2016 at 02:30:57PM -0700, Junio C Hamano wrote: > Torsten Bögershausen <[email protected]> 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
"This parser handles the urls described in urls.txt" is about as much as there is to say IMHO. > 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? After this series, there's only one use of get_host_and_port(). As well as one use of host_end() and get_port(). They become implementation details of the parse_connect_url function. And as I mentioned in the cover letter this round, parse_connect_url could be further modified to avoid the kind of back-and-forth that's going on between these functions. But I'd rather leave that for later. Mike -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
