On 28/08/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:

quoted text
> And that is how it was designed to be. The URL's are for *git*, not for
> other uses. If you want to do cross-SCM tools, you need to let them know
> it's a "git" thing wheher it's browsable or not, so the argument that ssh
> is something "different" is bogus crapola.

That throws out the *U* of *URL*, which stands for Uniform. If you
have to say whether a URL is a "git" URL or some other kind of URL,
it's no longer a Uniform Resource Locator.

However, to quote RFC 3986:
   Although many URI schemes are named after protocols, this does not
   imply that use of these URIs will result in access to the resource
   via the named protocol.  URIs are often used simply for the sake of
   identification.  Even when a URI is used to retrieve a representation
   of a resource, that access might be through gateways, proxies,
   caches, and name resolution services that are independent of the
   protocol associated with the scheme name.

Perhaps git:// URLs shouldn't be used at all, and we should just use
file://, ssh://, http://, etc., since the scheme is usually there to
explicitly denote the protocol we want to use, and the fact we're
using that protocol to do git work is implicit in the 'git' at the
start of the command-line. It makes sense to me that both 'git clone
<URL> foo' and 'rsync <URL> foo' would both work roughly the same,
assuming both git and rsync support the URL's scheme.


Dave.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html