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

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 10, 2009, 08:47 UTC
Message-ID: <7v63cw3vjv.fsf@alter.siamese.dyndns.org>
In-Reply-To: <alpine.LNX.2.00.0908092153520.27553@iabervon.org>

Daniel Barkalow <barkalow@iabervon.org> writes:

> I think that users should never need to know the names of the helpers. I 
> mean, the native protocol uses helpers that most users are completely 
> unaware of. The users do need to know what the

... heck ;-)?

But seriously, why not?

Show 9 quoted lines

> The problem is not that foreign systems don't have "urls" in particular. 
> The problem is that there are foreign systems, like perforce, where the 
> lines between different repositories in the git sense are drawn in very 
> different ways. In perforce, for example, there is a single namespace for 
> all branches of all projects hosted on the same server. It's like... 
> ...
> (and hundreds more, mixing all the branches of all of the repositories 
> for all of the projects, without any conventions beyond what the 
> community on the particular server made up)

That looks similar to a subversion server with multiple projects with multiple branches, and they seem to be able to use

    "svn://<whatever svn uses as its own convention>"

just fine.

Why p4 cannot do what svn can? Doesn't p4 ever "name" a repository/branch inside that "single namespace" with a simple string that is easy to remember for users? And if there is one, I do not see what prevents you from using "p4://<whatever information p4 users use>"?

Show 15 quoted lines

> You really need a different sort of configuration option to specify what 
> we think of as "the git.git repository", which includes certain branches 
> and doesn't include other projects hosted on kernel.org. And in order to 
> find the server, it uses an arbitrary shell command line that acts like 
> rsh (and often consists of "ssh" as the command and a bunch of complicated 
> options to connect to the right port of the right host to get the right 
> restricted shell with the right preset environment). So there's nothing 
> you can put in the <whatever string the helper understands> part, because 
> the helper really has to figure out what it's doing from a bunch of 
> options.
>
> Furthermore, I don't want to just use "p4:" as what people should use in 
> remote.*.url in order to select the right helper, because then people are 
> going to have different remotes with the same url option value in order to 
> access entirely different data.

Maybe it is the _primary_ itch you would want to scratch, but this does sound like a very special case that wants to have multiple pieces of pre-parsed information to identify a "repository".

Perhaps in such a case it would be equally valid if you said "p4:hello" and "p4:goodbye" to identify two "repositories", with p4-helper specific configuration option that is keyed off of of p4.hello.* and p4.goodbye.* namespace, e.g. (without knowing p4 at all)

	[remote "origin"]
        	url = p4:hello
	[p4 "hello"]
        	find-server-command = ssh bunch of complicated options
		random-p4-option = ...
		random-other-p4-option = ...

Of course it does not have to be called "url", and you could do the same thing with:

	[remote "origin"]
        	vcs = p4
	[p4 "origin"]
        	find-server-command = ssh bunch of complicated options
		random-p4-option = ...
		random-other-p4-option = ...

And probably there aren't much difference either way between these two appraoches. The former gives an extra name ("hello") that may simply be redundant, or perhaps adds value by descriptive, depending on your viewpoint.