On Mon, 31 Aug 2009, Junio C Hamano wrote: > 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 ;-)? That's just weird, and looks wrong to me, like ssh tunnelled over the git native protocol. I think, if we support it, it would have to be another special case. > 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. I was thinking that the dispatcher would always pass the whole thing, and the svn helper would have to deal with svn+http:// and svn+svn:// as well as svn+ssh://. The dispatcher shouldn't be familiar with what the backends do, but the backends could stand to be familiar with what might be there just to get to them. On the other hand, I don't have a good intuition for what makes sense to users of such systems, since I've only extensively used cvs, git, and perforce. > > 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. Fair enough. > >> 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. Agreed. > 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. I don't really have a particularly good guess about the case of vcs and a URL, because I haven't used systems that are not git and use URLs. -Daniel *This .sig left intentionally blank* -- 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