On Mon, 10 Aug 2009, Johan Herland wrote: > On Monday 10 August 2009, Daniel Barkalow wrote: > > On Sun, 9 Aug 2009, Junio C Hamano wrote: > > > Daniel Barkalow <barkalow@xxxxxxxxxxxx> writes: > > > > If this is set, the url is not required, and the transport always > > > > uses a helper named "git-remote-<value>". > > > > > > > > It is a separate configuration option in order to allow a sensible > > > > configuration for foreign systems which either have no meaningful > > > > urls for repositories or which require urls that do not specify the > > > > system used by the repository at that location. However, this only > > > > affects how the name of the helper is determined, not anything about > > > > the interaction with the helper, and the contruction is such that, if > > > > the foreign scm does happen to use a co-named url method, a url with > > > > that method may be used directly. > > > > > > Personally, I do not like this. > > > > > > Why isn't it enough to define the canonical remote name git takes as > > > "<name of the helper>:<whatever string the helper understands>"? > > > > [...] > > > > The only way I've been able to come up with to support this at all > > usefully is to have a bunch of helper-specific options that specify what > > the helper needs to know about the locations you consider to be part of > > the project and an option that tells git that this remote uses the p4 > > helper. I'm not sure what makes sense for other helpers, but the case I > > actually use needs something like what's in this patch. > > I'm somewhat agnostic on this issue. At the moment, I follow the P4 cues, > and use a config like this: > > [remote "foo"] > vcs = cvs > cvsRoot = ":pserver:user@xxxxxxxxxxxxxxxxxxxxxx/var/cvs/cvsroot" > cvsModule = "bar" > ... > > But I could just as well use a config like this instead: > > [remote "foo"] > url = "cvs::pserver:user@xxxxxxxxxxxxxxxxxxxxxx/var/cvs/cvsroot#bar" > ... > > Either is fine with me, although I suspect users might find the > current/first alternative easier to parse. I suspect there will be some users who want (1) and some who want (2), and both ought to work. > > I think it makes sense for svn access to support just having a url > > option like "svn://something (svn native protocol)", or > > "svn+ssh://something (svn protocol over ssh)" or "svn+https://something > > (https access to a svn repo)", or some other similar syntax, but this is > > a poor fit for p4. > > > > In order to support this, there just needs to be a call to check whether > > "remote-<something>" is an available git command (without running it or > > giving an error), and the helper code should be used if it is. This is > > actually required so that people with workstations whose domain is > > .kernel.org and who have cloned "master:/home/linus/something.git" don't > > start getting "remote-master isn't a git command" errors (that is, > > misinterpreting ssh-format location hostnames as helper names. Johan, > > perhaps you could write that for your CVS helper? > > Sorry, not following you here. Write exactly what? > > - The code in the transport layer for checking if "remote-<something>" > is an available git command? That's what I was thinking. > - The code in my CVS helper for handling the ssh-format misinterpretation, > i.e. the case where someone has a git/ssh server called "cvs"? If so, > how should this be handled? I'd been thinking that people's servers wouldn't be named "cvs", but they might be named things that aren't clearly not plausible names for helpers. So I don't think there should be a need to deal with misdirected names going to actual helpers, just names for helpers that don't exist. > > I think that, ideally, helpers for foreign systems would be portable > > across multiple native systems. The svn helper could be a program > > "svn-remote-access-helper", and anything that speaks fast-import (e.g., > > bzr or hg) would be able to use it. When installing it for git, you'd > > symlink it to git-remote-svn; if you decided to install > > "svn-remote-access-helper-ng", you'd change the symlink. > > In that case, helpers must keep their metadata in a repo-independent > format. Currently that is outside the scope of my CVS helper, since I'm > leveraging git-notes for most of the CVS helper's metadata. Yeah, that's one of several tricky issues. I don't think there's enough experience yet to design something to support portable helpers, but I think it's worth thinking about. -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