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 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?
- 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 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.
...Johan
--
Johan Herland, <johan@xxxxxxxxxxx>
www.herland.net
--
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