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

> 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?
>