Johannes Schindelin [off-list ref] 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.
Here are two URLs that follows your "user convenience" principle.
http://example.xz/repos/frotz.git/
http://example.xz/repo/frotz/trunk/
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)
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.
A corollary to this is that you can also use "git svn init" on it.
Compared to that, if you do not have any such prefix, how would that be
more convenient to the users?
Or perhaps you have an alternative in mind that is more convenient for the
users and that is not "use identically looking http://... for both", but
you are being unnecessarily cryptic by not spelling out what it is.
Hi,
On Fri, 4 Sep 2009, Junio C Hamano wrote:
Johannes Schindelin [off-list ref] writes:
quoted
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