Re: git_inetd_server: run git-http-backend using inetd
- From
Kyle J. McKay <mackyle@gmail.com>
- Date
- Jul 19, 2014, 01:54 UTC
- 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:
Show 15 quoted lines
> 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.