Re: [PATCH 5/8] Add a config option for remotes to specify a foreign vcs

> On Monday 10 August 2009, Daniel Barkalow wrote:
> > On Sun, 9 Aug 2009, Junio C Hamano wrote:
> > > Daniel Barkalow <barkalow@iabervon.org> 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@cvs.server.example.com/var/cvs/cvsroot"
>         cvsModule = "bar"
>         ...
> 
> But I could just as well use a config like this instead:
> 
>     [remote "foo"]
>         url = "cvs::pserver:user@cvs.server.example.com/var/cvs/cvsroot#bar"
>         ...
> 
> Either is fine with me, although I suspect users might find the
> current/first alternative easier to parse.

> > 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?

> > 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.