Re: git_inetd_server: run git-http-backend using inetd

Kyle J. McKay wrote:

On Jul 18, 2014, at 10:16, Jonathan Nieder wrote:

quoted

Kyle J. McKay wrote:

quoted

quoted

You might also want to take a look at [1] which suggests that when
doing SRV lookups for URLs they should be done regardless of whether
or not a port number is present (which then eliminates the RFC 3986
issue the current SRV lookup code has).

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

quoted

What would be the interoperability advantage of making
them URIs?

According to RFC 3968 they are already considered URIs.

I don't think you understood my question.

quoted

This has come up before, with e.g. people asking to introduce a
git+ssh:// and git+http://

How is a discussion about changing the scheme name relevant to a
discussion about treating a URL with an explicit default port the
same as one without (which Git already does but stops doing with the
0010 git SRV patch)?

It's where the question of whether the things you pass to 'git clone'
are URIs came up before.

I don't understand what you want in this side-conversation.  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?  I can easily be
convinced some other way, but "It's in a standard that you never
intended to follow" is not particularly convincing or relevant.

The same philosophy as the git project applies to POSIX conformance
issues applies here, too.  We live in the real world.

Hoping that clarifies,
Jonathan