From: Kyle J. McKay <mackyle@gmail.com>
Date: Sat, 19 Jul 2014 01:54:08 GMT
Subject: Re: git_inetd_server: run git-http-backend using inetd
Message-ID: <1A68D760-F69C-4DBE-AEAC-6672626A9515@gmail.com>
In-Reply-To: <20140719001908.GX12427@google.com>

On Jul 18, 2014, at 17:19, Jonathan Nieder wrote:

> Kyle J. McKay wrote:
>> On Jul 18, 2014, at 10:16, Jonathan Nieder wrote:
>>>
>>> "Git URLs" as described e.g. in git-clone(1) weren't intended to be
>>> actual URIs.
>>
>> According to RFC 3968 section 1.1.3:
>> "A URI can be further classified as a locator, a name, or both. The
>> term "Uniform Resource Locator" (URL) refers to the subset of URIs"
>> [...]
>>
>> So actually they are URIs.
>
> You mean abusing the word URL when we meant URL-shaped thing makes it
> into a URL?

That is your contention.

> Do you
> mean that I should read that RFC and be convinced that what you are
> saying about ports is the right thing to do?

It's the right thing to do because it's the standard for how URLs are  
expected to behave.

> "It's in a standard that you never
> intended to follow" is not particularly convincing or relevant.

That is your contention.  If it is truly the case that where the Git  
documentation uses the "URL" acronym that Git does not actually intend  
for "URL" to be interpreted as a "URL" as defined by the various  
standards covering such URLs then explicit text needs to be added to  
the documentation saying so to avoid confusion.  In the absence of  
such text, expecting a reader of Git documentation to interpret the  
term "URL" any other way is irrational.