Re: [PATCH 1/3] connect.c: Improve parsing of literal IPV6 addresses

From: Junio C Hamano <gitster@pobox.com>
To: "Torsten Bögershausen" <tboegi@web.de>
Cc: "brian m. carlson" <sandals@crustytoothpaste.net>,
	git@vger.kernel.org, lists@hcf.yourweb.de
Subject: Re: [PATCH 1/3] connect.c: Improve parsing of literal IPV6 addresses
Date: Thu, 19 Feb 2015 09:54:52 -0800	[thread overview]
Message-ID: <xmqq386123df.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <54E61285.5070600@web.de> ("Torsten =?utf-8?Q?B=C3=B6gershaus?= =?utf-8?Q?en=22's?= message of "Thu, 19 Feb 2015 17:42:45 +0100")

Torsten Bögershausen <tboegi@web.de> writes:

> On 02/18/2015 07:40 PM, Junio C Hamano wrote:
>> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
>>
>>> I understand that this used to work, but it probably shouldn't have
>>> ever been accepted.  It's nonstandard, and if we accept it for ssh,
>>> people will want it to work for https, and due to libcurl, it simply
>>> won't.
>>>
>>> I prefer to see our past acceptance of this format as a bug.  This is
>>> the first that I've heard of anyone noticing this (since 2013), so it
>>> can't be in common usage.
>>>
>>> If we accept it, we should explicitly document it as being deprecated
>>> and note that it's inconsistent with the way everything else works.
>> I was reviewing my Undecided pile today, and I think your objection
>> makes sense.
>>
>> Either of you care to update documentation, please, before I drop
>> this series and forget about it?
>
> The URL RFC is much stricter regarding which characters that are allowed
> in which part of the URL, as least as I read it.
> ...
> I'm somewhat unsure what to write in the documentation, I must admit.

I can see that you do not agree with the "If we accept it" part
(where "it" refers to "allowing [...] was a bug.")---past acceptance
was not a bug for you.

Brian is for that "If we accept it", and sees it as a bug.

So let's see what he comes up with as a follow-up to the "we should
explicitly document it" part.