Hi, On Fri, 4 Sep 2009, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > The special case is "http://"; and "https://"; which might indicate foreign > > VCS repositories. > > > > In all other cases, I am afraid that you are complicating the glove. > > > > Remember: the whole purpose of the "foreign VCS" helpers is user > > convenience. > > Sorry, but you completely lost me here. My point was that the ambiguity _only_ applies to http:// and https:// URLs, as you illustrated yourself: > Here are two URLs that follows your "user convenience" principle. > > http://example.xz/repos/frotz.git/ > http://example.xz/repo/frotz/trunk/ There is no ambiguity about hg://, svn://, etc. None. Some "URLs" do not look like "URLs" at all, e.g. :ext:user@host:/module for CVS repositories. I haven't really thought about a convenient way to specify these, but I could imagine that indeed something like "cvs::ext:usr@host:/module" would make sense, and still be an intuitive interface that does not break down with "git clone". Likewise, I imagine that "svn::http://example.xz/repo/frotz/trunk"; (or even "svn::std::http://example.xz/repo/frotz";) are not _too_ unintuitive. But my real point still stands: "git clone hg://example.xz/repos/blub" should Just Work. Oh, and I definitely do not want to expose an _implementation detail_ such as "we use cURL" in the name of the remote helper. That would just be bad style in my book. > How do you tell, without relying on .git and trunk, the former is a git > repository and wants the dumb walker transport to fetch from, while the > latter is probably a svn and you would either use "svn checkout", or use > "git clone" on it via the svn helper? > > Well, you don't. > > One possible "convenient user interface" would be to say > > svn+http://example.xz/repo/frotz/trunk/ > > (or use :: instead of + as the helper-name separator, as we agreed not to > decide on it) Now that you mention it, the main issue was the ambiguity that svn:/path/to/repo should actually be an ssh "URL". But I think that the simple fact that a "://" in the URL (and if that is not sufficient, something like a "<vcs>::" prefix) make non-ssh URLs distinct enough to decide robustly what type the URL is. > This would give us > > (1) it is clear that it literally is what you would give to git and > trigger the svn helper; and > > (2) to people who know how canonical git URLs with foreign helper are > spelled, it also is clear that you can use "svn checkout" on > everything after "svn+" in it. The only problem is that you cannot use "git-remote-svn+http" as helper, as "+" are not valid filename characters on Windows. However, you could have a "git-remote-svn" handling both "svn://" and "svn+" prefixes. > Compared to that, if you do not have any such prefix, how would that be > more convenient to the users? Indeed, I made myself misunderstood. I think that for _a lot_ of repository URLs, there are naturally distinctive-enough prefixes. IMHO we should make use of that, for a substantially improved user experience (as opposed to, say, the user experience for unfortunate CVS users who would like to establish a git-svn-like workflow). Summary: I think that for most URLs, "<protocol>://" is enough to tell which helper to call ("http://"; means Git, tough). For those URLs, where this is not sufficient, a "<vcs>+" should be good enough, or if you really want, "<vcs>::". As the helper gets the complete URL, it can figure out how to proceed from here, without any need for core Git to know how. Ciao, Dscho -- 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