On 28/08/07, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
