threads / patch / 20393

patch, 13 partsAdd a config option for remotes to specify a foreign vcs

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

## tl;dr

17 messages between Aug 5, 2009 and Aug 5, 2009. Diffs are folded; open one to read it.

replies: 16people: 4as markdown or json

Daniel Barkalow· Aug 5, 2009, 05:02 UTC · lore

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 <barkalow@iabervon.org>
---
 Documentation/config.txt |    4 ++++
 remote.c                 |    4 +++-
 remote.h                 |    2 ++
 transport-helper.c       |   14 ++++++++++----
 transport.c              |    5 +++++
 5 files changed, 24 insertions(+), 5 deletions(-)
Show changes to 5 files +24 −5

Documentation/config.txt, remote.c, remote.h, transport-helper.c, transport.c

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
Brian Gernhardt· Aug 5, 2009, 05:09 UTC · re: Daniel Barkalow · lore

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

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
Daniel Barkalow· Aug 5, 2009, 05:19 UTC · re: Brian Gernhardt · lore

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

On Wed, 5 Aug 2009, Brian Gernhardt wrote:
Show 11 quoted lines
> 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.
True; git-remote-<vcs> is the correct name.
	-Daniel
*This .sig left intentionally blank*
Johannes Schindelin· Aug 5, 2009, 20:53 UTC · re: Daniel Barkalow · lore

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

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

Daniel Barkalow· Aug 5, 2009, 21:07 UTC · re: Johannes Schindelin · lore

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

On Wed, 5 Aug 2009, Johannes Schindelin wrote:
Show 9 quoted lines
> 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.

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*
Johannes Schindelin· Aug 5, 2009, 21:20 UTC · re: Daniel Barkalow · lore

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

Hi,
On Wed, 5 Aug 2009, Daniel Barkalow wrote:
Show 13 quoted lines
> On Wed, 5 Aug 2009, Johannes Schindelin wrote:
> 
> > 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.
> 
> 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

Sverre Rabbelier· Aug 5, 2009, 21:46 UTC · re: Johannes Schindelin · lore

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

Heya,

On Wed, Aug 5, 2009 at 14:20, Johannes Schindelin<Johannes.Schindelin@gmx.de> 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
Johannes Schindelin· Aug 5, 2009, 21:50 UTC · re: Sverre Rabbelier · lore

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

Hi,
On Wed, 5 Aug 2009, Sverre Rabbelier wrote:
Show 7 quoted lines
> On Wed, Aug 5, 2009 at 14:20, Johannes 
> Schindelin<Johannes.Schindelin@gmx.de> 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?
Problem: on Windows, we cannot name the helper git-remote-http+svn: "+" is 
not an allowed character in a filename.

Ciao, Dscho

Sverre Rabbelier· Aug 5, 2009, 21:53 UTC · re: Johannes Schindelin · lore

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

Heya,

On Wed, Aug 5, 2009 at 14:50, Johannes Schindelin<Johannes.Schindelin@gmx.de> 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
Johannes Schindelin· Aug 5, 2009, 22:04 UTC · re: Sverre Rabbelier · lore

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

Hi,
On Wed, 5 Aug 2009, Sverre Rabbelier wrote:
Show 10 quoted lines
> On Wed, Aug 5, 2009 at 14:50, Johannes
> Schindelin<Johannes.Schindelin@gmx.de> 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.
Yes, I agree: svn:http:// is much better.

Ciao, Dscho

Sverre Rabbelier· Aug 5, 2009, 22:05 UTC · re: Johannes Schindelin · lore

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

Heya,

On Wed, Aug 5, 2009 at 15:04, Johannes Schindelin<Johannes.Schindelin@gmx.de> wrote:

> Yes, I agree: svn:http:// is much better.
Was that sarcasm? (I just realized that ':' is also a forbidden character)
-- 
Cheers,

Sverre Rabbelier
Johannes Schindelin· Aug 5, 2009, 22:12 UTC · re: Sverre Rabbelier · lore

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

Hi,
On Wed, 5 Aug 2009, Sverre Rabbelier wrote:
Show 6 quoted lines
> On Wed, Aug 5, 2009 at 15:04, Johannes 
> Schindelin<Johannes.Schindelin@gmx.de> wrote:
> > 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

Sverre Rabbelier· Aug 5, 2009, 22:15 UTC · re: Johannes Schindelin · lore

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

Heya,

On Wed, Aug 5, 2009 at 15:12, Johannes Schindelin<Johannes.Schindelin@gmx.de> 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
Daniel Barkalow· Aug 5, 2009, 22:15 UTC · re: Sverre Rabbelier · lore

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

On Wed, 5 Aug 2009, Sverre Rabbelier wrote:
Show 7 quoted lines
> Heya,
> 
> On Wed, Aug 5, 2009 at 15:04, Johannes
> Schindelin<Johannes.Schindelin@gmx.de> wrote:
> > 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*
Daniel Barkalow· Aug 5, 2009, 22:09 UTC · re: Johannes Schindelin · lore

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

On Wed, 5 Aug 2009, Johannes Schindelin wrote:
Show 14 quoted lines
> Hi,
> 
> On Wed, 5 Aug 2009, Sverre Rabbelier wrote:
> 
> > On Wed, Aug 5, 2009 at 14:20, Johannes 
> > Schindelin<Johannes.Schindelin@gmx.de> 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?
> 
> 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*
Daniel Barkalow· Aug 5, 2009, 21:46 UTC · re: Johannes Schindelin · lore

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

On Wed, 5 Aug 2009, Johannes Schindelin wrote:
Show 20 quoted lines
> Hi,
> 
> On Wed, 5 Aug 2009, Daniel Barkalow wrote:
> 
> > On Wed, 5 Aug 2009, Johannes Schindelin wrote:
> > 
> > > 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.
> > 
> > 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*
Johannes Schindelin· Aug 5, 2009, 21:53 UTC · re: Daniel Barkalow · lore

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

Hi,
On Wed, 5 Aug 2009, Daniel Barkalow wrote:
Show 30 quoted lines
> On Wed, 5 Aug 2009, Johannes Schindelin wrote:
> 
> > Hi,
> > 
> > On Wed, 5 Aug 2009, Daniel Barkalow wrote:
> > 
> > > On Wed, 5 Aug 2009, Johannes Schindelin wrote:
> > > 
> > > > 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.
> > > 
> > > 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

← back to recent threads