Daniel Barkalow <barkalow@xxxxxxxxxxxx> writes:
> On Sat, 29 Aug 2009, Junio C Hamano wrote:
>
>> ..., if only to avoid confusion with our own earlier misdesigned
>> syntax git+ssh://), so the canonical syntax would be:
>
> (with the syntax <helper>+, "git+ssh://" would specify the helper "git",
> which is as good an explicit identifier of the internal handling as any)
Sure but how would you explain "ssh+git://" then ;-)?
Luckily neither is advertised in our documentation set as far as I can
tell, so I do not think it is a huge deal between + vs ::, but as Peff
says in
http://thread.gmane.org/gmane.comp.version-control.git/125615
I think the latter is probably less problematic.
With plus, a helper that talks with a Subversion repository whose native
URL is http://host/path would look like svn+http://host/path, which is
reasonable. When talking the Subversion protocol over SSH, however, the
native URL for the repository would be svn+ssh://host/path, so the URL
with helper name on our side becomes svn+svn+ssh://host/path. We could
recognize "svn+" part and implicitly pass the whole thing to svn helper
upon seeing svn+ssh://host/path, but I do not think we would want to make
the dispatcher too familiar with what the backends do. Using something
other than plus sign would avoid this issue.
> If the policy is that we're going to have "traditionally supported"
> schemes, where the internal code knows what helper supports them, I can
> fix up the series so that the curl-based helper is named "curl", and we
> can say that the check for "http://";, "ftp://";, and "https://"; is
> recognizing traditionally-supported schemes, and we can defer coming up
> with what the syntax for the explicit handler selection is. (For that
> matter, if there's a // after the colon, it's obviously not a
> handy ssh-style location, since the second slash would do nothing)
That sounds like a sane approach to first get the "eject curl from
builtin" out the door. We might extend the dispatcher in the future by
changing "traditionally supported" criterion to "commonly used",
e.g. recognize "svn+ssh://" as something the svn helper would want to
handle, but that is a future extension we do not have to address right
now.
>> After you explained this in the thread (I think for the second time), I
>> see no problem with this, except that I think to support this we should
>> notice and raise an error when we see a remote has both vcs and url,
>> because the only reason we would want to say "vcs", if I recall your
>> explanation correctly, is that such a transport does not have the concept
>> of URL, i.e. a well defined single string that identifies the repository.
>
> A user who mostly uses Perforce as a foreign repositories but is using a
> SVN repo on occasion might want to use "vcs" regardless, but I agree with
> forcing the helper to use a different option for the case of a URL that
> git isn't going to look at. That is, you ought to be able to use:
>
> [remote "origin"]
> vcs = svn
> (something) = http://svn.savannah.gnu.org/...
>
> But "(something)" shouldn't be "url".
I actuallly do not have a strong opinion on this one either way. I said
"I think" when I suggested it, but it was actually without thinking too
deeply, hoping that you would come up with a good counter-argument.
For example, if we envision that for most of the helpers there will be one
primary string that identifies the repository, but the primary string
alone is not enough for the helper without some auxiliary information, it
would be natural to use remote.$name.url for that primary string. I do
not know if that would be the case, but I was hoping that you would have a
better intuition[*1*], as you have thought this topic through a lot longer
and deeper than I have. So I'd rather leave the decision on that "no
vcs/url at the same time restriction" up to you. It is in general easier
to start more strict and then loosen the restiction later, than the other
way around, when we cannot decide, though.
Thanks.
[Footnote]
*1* What I mean by intuition is that you do not have to have the right
answer backed by research _now_, but have a good guess as to what the
right answer would be.
--
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