Re: [PATCH v7 1/9] connect: document why we sometimes call get_port after get_host_and_port

[Junio C Hamano <gitster@pobox.com>]

Torsten Bögershausen <tboegi@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?