[PATCH 07/13] Add a config option for remotes to specify a foreign vcs

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.

Signed-off-by: Daniel Barkalow <redacted>
---
 Documentation/config.txt |    4 ++++
 remote.c                 |    4 +++-
 remote.h                 |    2 ++
 transport-helper.c       |   14 ++++++++++----
 transport.c              |    5 +++++
 5 files changed, 24 insertions(+), 5 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index c6f09f8..6763c4b 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt

@@ -1364,6 +1364,10 @@ remote.<name>.tagopt::
 	Setting this value to \--no-tags disables automatic tag following when
 	fetching from remote <name>
 
+remote.<name>.vcs::
+	Setting this to a value <vcs> will cause git to interact with
+	the remote with the git-vcs-<vcs> helper.
+
 remotes.<group>::
 	The list of remotes which are fetched by "git remote update
 	<group>".  See linkgit:git-remote[1].

diff --git a/remote.c b/remote.c
index e6f5cd2..057ac02 100644
--- a/remote.c
+++ b/remote.c

@@ -50,7 +50,7 @@ static char buffer[BUF_SIZE];
 
 static int valid_remote(const struct remote *remote)
 {
-	return !!remote->url;
+	return remote->url || remote->foreign_vcs;
 }
 
 static const char *alias_url(const char *url)

@@ -427,6 +427,8 @@ static int handle_config(const char *key, const char *value, void *cb)
 	} else if (!strcmp(subkey, ".proxy")) {
 		return git_config_string((const char **)&remote->http_proxy,
 					 key, value);
+	} else if (!strcmp(subkey, ".vcs")) {
+		return git_config_string(&remote->foreign_vcs, key, value);
 	}
 	return 0;
 }

diff --git a/remote.h b/remote.h
index 5db8420..ac0ce2f 100644
--- a/remote.h
+++ b/remote.h

@@ -11,6 +11,8 @@ struct remote {
 	const char *name;
 	int origin;
 
+	const char *foreign_vcs;
+
 	const char **url;
 	int url_nr;
 	int url_alloc;

diff --git a/transport-helper.c b/transport-helper.c
index 203a056..dccf400 100644
--- a/transport-helper.c
+++ b/transport-helper.c

@@ -155,10 +155,16 @@ static struct ref *get_refs_list(struct transport *transport, int for_push)
 int transport_helper_init(struct transport *transport)
 {
 	struct helper_data *data = xcalloc(sizeof(*data), 1);
-	char *eom = strchr(transport->url, ':');
-	if (!eom)
-		return -1;
-	data->name = xstrndup(transport->url, eom - transport->url);
+
+	if (transport->remote->foreign_vcs) {
+		data->name = xstrdup(transport->remote->foreign_vcs);
+		transport->url = transport->remote->foreign_vcs;
+	} else {
+		char *eom = strchr(transport->url, ':');
+		if (!eom)
+			return -1;
+		data->name = xstrndup(transport->url, eom - transport->url);
+	}
 
 	transport->data = data;
 	transport->get_refs_list = get_refs_list;

diff --git a/transport.c b/transport.c
index 983d183..b5dcdc7 100644
--- a/transport.c
+++ b/transport.c

@@ -813,6 +813,11 @@ struct transport *transport_get(struct remote *remote, const char *url)
 		url = remote->url[0];
 	ret->url = url;
 
+	if (remote && remote->foreign_vcs) {
+		transport_helper_init(ret);
+		return ret;
+	}
+
 	if (!prefixcmp(url, "rsync:")) {
 		ret->get_refs_list = get_refs_via_rsync;
 		ret->fetch = fetch_objs_via_rsync;

-- 
1.6.4.rc3.27.g95032.dirty

On Aug 5, 2009, at 1:02 AM, Daniel Barkalow wrote:

If this is set, the url is not required, and the transport always uses
a helper named "git-remote-<value>".

+remote.<name>.vcs::
+	Setting this to a value <vcs> will cause git to interact with
+	the remote with the git-vcs-<vcs> helper.

I can't tell from the code, but one of these has to be wrong.

~~ Brian

On Wed, 5 Aug 2009, Brian Gernhardt wrote:

On Aug 5, 2009, at 1:02 AM, Daniel Barkalow wrote:

quoted

If this is set, the url is not required, and the transport always uses
a helper named "git-remote-<value>".

quoted

+remote.<name>.vcs::
+	Setting this to a value <vcs> will cause git to interact with
+	the remote with the git-vcs-<vcs> helper.

I can't tell from the code, but one of these has to be wrong.

True; git-remote-<vcs> is the correct name.

	-Daniel
*This .sig left intentionally blank*

Hi,

On Wed, 5 Aug 2009, Daniel Barkalow wrote:

If this is set, the url is not required, and the transport always uses a 
helper named "git-remote-<value>".

I wonder what's wrong with saying "git config remote.origin.url p4:" 
instead of having two different code paths that do essentially the same.

Ciao,
Dscho

On Wed, 5 Aug 2009, Johannes Schindelin wrote:

Hi,

On Wed, 5 Aug 2009, Daniel Barkalow wrote:

quoted

If this is set, the url is not required, and the transport always uses a 
helper named "git-remote-<value>".

I wonder what's wrong with saying "git config remote.origin.url p4:" 
instead of having two different code paths that do essentially the same.

I believe some cases will want to use a URL which is "http://something" 
and have some other option cause the code to use "git helper-svn". I think 
it's necessary to distinguish *where* the repo is (which includes how you 
reach it) from *what* the repo is. I don't think it's necessary to have 
the helper naming distinguish which was used, but both mechanisms need to 
be available for deciding.

	-Daniel
*This .sig left intentionally blank*

Hi,

On Wed, 5 Aug 2009, Daniel Barkalow wrote:

On Wed, 5 Aug 2009, Johannes Schindelin wrote:

quoted

On Wed, 5 Aug 2009, Daniel Barkalow wrote:

quoted

If this is set, the url is not required, and the transport always 
uses a helper named "git-remote-<value>".

I wonder what's wrong with saying "git config remote.origin.url p4:" 
instead of having two different code paths that do essentially the 
same.

I believe some cases will want to use a URL which is "http://something" 
and have some other option cause the code to use "git helper-svn".

I actually would rather have "svn-http://something" because it tells me 
right away and in red letters what is happening.

Ciao,
Dscho

On Wed, 5 Aug 2009, Johannes Schindelin wrote:

Hi,

On Wed, 5 Aug 2009, Daniel Barkalow wrote:

quoted

On Wed, 5 Aug 2009, Johannes Schindelin wrote:

quoted

On Wed, 5 Aug 2009, Daniel Barkalow wrote:

quoted

If this is set, the url is not required, and the transport always 
uses a helper named "git-remote-<value>".

I wonder what's wrong with saying "git config remote.origin.url p4:" 
instead of having two different code paths that do essentially the 
same.

I believe some cases will want to use a URL which is "http://something" 
and have some other option cause the code to use "git helper-svn".

I actually would rather have "svn-http://something" because it tells me 
right away and in red letters what is happening.

I think it's much more useful to have the URL that git uses for a 
subversion repo be identical to the URL that svn uses for the same repo.

Of course, users should also be able to use something like 
"svn-http://something" or "svn:http://something", but I think we'd get a 
lot of confusion if we don't support a remote.*.url of exactly what a 
svn-using project webpage says their repo url is.

	-Daniel
*This .sig left intentionally blank*

Heya,

On Wed, Aug 5, 2009 at 14:20, Johannes
Schindelin[off-list ref] wrote:

I actually would rather have "svn-http://something" because it tells me
right away and in red letters what is happening.

I don't know if this is only for ssh, but wouldn't
"http+svn://something" be very recognisable?

-- 
Cheers,

Sverre Rabbelier

Hi,

On Wed, 5 Aug 2009, Daniel Barkalow wrote:

On Wed, 5 Aug 2009, Johannes Schindelin wrote:

quoted

Hi,

On Wed, 5 Aug 2009, Daniel Barkalow wrote:

quoted

On Wed, 5 Aug 2009, Johannes Schindelin wrote:

quoted

On Wed, 5 Aug 2009, Daniel Barkalow wrote:

quoted

If this is set, the url is not required, and the transport always 
uses a helper named "git-remote-<value>".

I wonder what's wrong with saying "git config remote.origin.url p4:" 
instead of having two different code paths that do essentially the 
same.

I believe some cases will want to use a URL which is "http://something" 
and have some other option cause the code to use "git helper-svn".

I actually would rather have "svn-http://something" because it tells me 
right away and in red letters what is happening.

I think it's much more useful to have the URL that git uses for a 
subversion repo be identical to the URL that svn uses for the same repo.

Of course, users should also be able to use something like 
"svn-http://something" or "svn:http://something", but I think we'd get a 
lot of confusion if we don't support a remote.*.url of exactly what a 
svn-using project webpage says their repo url is.

And I will _constantly_ be confused when the URL looks the same for Git 
and for SVN repositories.

Adding another config option to specify which helper processes the URL is 
not helping me in any way.  Rather the opposite.

Ciao,
Dscho

Heya,

On Wed, Aug 5, 2009 at 14:50, Johannes
Schindelin[off-list ref] wrote:

Problem: on Windows, we cannot name the helper git-remote-http+svn: "+" is
not an allowed character in a filename.

Then do a s/+/-/ before calling the helper; no-one said the
translation between protocol name and helper name had to be 1:1, as
long as we document it there is no reason not to? Then again, maybe
it's more better to use 'svn-http" or 'svn:http' to make it obvious
that it's a special feature thingy.

-- 
Cheers,

Sverre Rabbelier

Hi,

On Wed, 5 Aug 2009, Sverre Rabbelier wrote:

On Wed, Aug 5, 2009 at 14:50, Johannes
Schindelin[off-list ref] wrote:

quoted

Problem: on Windows, we cannot name the helper git-remote-http+svn: "+" is
not an allowed character in a filename.

Then do a s/+/-/ before calling the helper; no-one said the
translation between protocol name and helper name had to be 1:1, as
long as we document it there is no reason not to? Then again, maybe
it's more better to use 'svn-http" or 'svn:http' to make it obvious
that it's a special feature thingy.

Yes, I agree: svn:http:// is much better.

Ciao,
Dscho

Heya,

On Wed, Aug 5, 2009 at 15:04, Johannes
Schindelin[off-list ref] wrote:

Yes, I agree: svn:http:// is much better.

Was that sarcasm? (I just realized that ':' is also a forbidden character)

-- 
Cheers,

Sverre Rabbelier

On Wed, 5 Aug 2009, Johannes Schindelin wrote:

Hi,

On Wed, 5 Aug 2009, Sverre Rabbelier wrote:

quoted

On Wed, Aug 5, 2009 at 14:20, Johannes 
Schindelin[off-list ref] wrote:

quoted

I actually would rather have "svn-http://something" because it tells 
me right away and in red letters what is happening.

I don't know if this is only for ssh, but wouldn't
"http+svn://something" be very recognisable?

Problem: on Windows, we cannot name the helper git-remote-http+svn: "+" is 
not an allowed character in a filename.

Also, the ssh thing is "svn+ssh", so it should be "svn+http".

The transport code could know that, if there's a + before the colon, the 
relevant part is before the +; I think the svn helper should have to take 
care of whatever access to svn is requested (perhaps itself using a 
transport-layer protocol helper, and if you say "svn+uucp://something", it 
should be up to the svn helper to tell you you're nuts, not git failing to 
find a svn+uucp helper. In particular, if the svn helper uses a library to 
do its network access, the URLs it can handle may vary arbitrarily, even 
when you're not changing the package with git-remote-svn in it, so it 
shouldn't be a matter of what names the svn helper is available under in 
the filesystem.

In any case, we do want to support SVN repos at "svn+ssh://something" 
somehow, and I think users will go crazy if it isn't either sticking that 
in the URL or also setting another option to "svn" (the latter probably 
being unfortunate to require).

	-Daniel
*This .sig left intentionally blank*

Hi,

On Wed, 5 Aug 2009, Sverre Rabbelier wrote:

On Wed, Aug 5, 2009 at 15:04, Johannes 
Schindelin[off-list ref] wrote:

quoted

Yes, I agree: svn:http:// is much better.

Was that sarcasm? (I just realized that ':' is also a forbidden 
character)

No sarcasm needed: the URL svn:http://sverre.ismy.he.ro/ is handled by the 
helper git-remote-svn (not git-remote-svn:http).

Ciao,
Dscho

On Wed, 5 Aug 2009, Sverre Rabbelier wrote:

Heya,

On Wed, Aug 5, 2009 at 15:04, Johannes
Schindelin[off-list ref] wrote:

quoted

Yes, I agree: svn:http:// is much better.

Was that sarcasm? (I just realized that ':' is also a forbidden character)

svn:http://... clearly works on the transport side; it'll run 
"git helper-svn", not "git helper-svn:http". The helper would have to know 
not to run svn with the URL being svn:http://... (which would probably 
cause it to use the native svn protocol), of course.

	-Daniel
*This .sig left intentionally blank*

Heya,

On Wed, Aug 5, 2009 at 15:12, Johannes
Schindelin[off-list ref] wrote:

No sarcasm needed: the URL svn:http://sverre.ismy.he.ro/ is handled by the
helper git-remote-svn (not git-remote-svn:http).

Hehe. So how would we store a svn repository at "svn+ssh://something"?

svn:svn+ssh://something ?

-- 
Cheers,

Sverre Rabbelier

Hi,

On Wed, 5 Aug 2009, Sverre Rabbelier wrote:

On Wed, Aug 5, 2009 at 14:20, Johannes 
Schindelin[off-list ref] wrote:

quoted

I actually would rather have "svn-http://something" because it tells 
me right away and in red letters what is happening.

I don't know if this is only for ssh, but wouldn't
"http+svn://something" be very recognisable?

Problem: on Windows, we cannot name the helper git-remote-http+svn: "+" is 
not an allowed character in a filename.

Ciao,
Dscho