[PATCH] Add support for host aliases in config files

[PATCH] Add support for host aliases in config files

[Daniel Barkalow]

This allows users with different preferences for access methods to the
same remote repositories to rewrite each other's URLs by pattern
matching across a large set of similiarly set up repositories to each
get the desired access.

Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
I still need to work more on the documentation (and I think I'd failed to 
come up with an organization for it that I liked), but I'd like to get the 
code portion out there are reviewed, at least, since I think last time, 
the patch only got as far as a discussion of how I should explain what it 
does.

 Documentation/config.txt |   22 +++++++++
 Documentation/urls.txt   |   25 ++++++++++
 remote.c                 |  112 ++++++++++++++++++++++++++++++++++++++++++++-
 3 files changed, 156 insertions(+), 3 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index f2f6a77..6ccd59f 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -646,6 +646,28 @@ help.format::
 	Values 'man', 'info', 'web' and 'html' are supported. 'man' is
 	the default. 'web' and 'html' are the same.
 
+host.<name>.*::
+	These options provide a way to rewrite URLs when there is a
+	pattern of URLs with a common prefix which should be replaced
+	with a different prefix. For every 'alias' prefix given, any
+	URL git receives that starts with that prefix will be
+	rewritten to have the 'base' prefix instead. In cases where
+	some site serves a large number of repositories, and serves
+	them with multiple access methods, and some users need to use
+	different access methods, this feature allows people to
+	specify any of the equivalent URLs and have git automatically
+	rewrite the URL to the best alternative for the particular
+	user, even for a never-before-seen repository on the site.
+
+host.<name>.base::
+	The base URL which should be used for this particular
+	host.
+
+host.<name>.rewritebase::
+	Additional base URLs which refer to this host. If a URL
+	matches this, any access to it will use the URL formed with
+	the corresponding base URL instead of the given URL.
+
 http.proxy::
 	Override the HTTP proxy, normally configured using the 'http_proxy'
 	environment variable (see linkgit:curl[1]).  This can be overridden
diff --git a/Documentation/urls.txt b/Documentation/urls.txt
index 81ac17f..11c05db 100644
--- a/Documentation/urls.txt
+++ b/Documentation/urls.txt
@@ -44,3 +44,28 @@ endif::git-clone[]
 ifdef::git-clone[]
 They are equivalent, except the former implies --local option.
 endif::git-clone[]
+
+
+If there are a large number of similarly-named remote repositories and
+you want to use a different format for them (such that the URLs you
+use will be rewritten into URLs that work), you can create a
+configuration section of the form:
+
+------------
+	[host "<host>"]
+		base = <actual url base>
+		rewritebase = <other url base>
+------------
+
+If you have a section:
+
+------------
+	[host "xz"]
+		base = git://git.host.xz/
+		rewritebase = host.xz:/path/to/
+		rewritebase = work:
+------------
+
+a URL like "work:repo.git" or like "host.xz:/path/to/repo.git" will be
+rewritten in any context that takes a URL to be
+"git://git.host.xz/repo.git".
diff --git a/remote.c b/remote.c
index 6b56473..59338a3 100644
--- a/remote.c
+++ b/remote.c
@@ -2,6 +2,15 @@
 #include "remote.h"
 #include "refs.h"
 
+struct host {
+	const char *name;
+
+	const char *base;
+
+	const char **alias;
+	int alias_nr;
+};
+
 static struct remote **remotes;
 static int allocated_remotes;
 
@@ -11,9 +20,32 @@ static int allocated_branches;
 static struct branch *current_branch;
 static const char *default_remote_name;
 
+static struct host **hosts;
+static int allocated_hosts;
+
 #define BUF_SIZE (2048)
 static char buffer[BUF_SIZE];
 
+static const char *alias_url(const char *url)
+{
+	int i, j;
+	for (i = 0; i < allocated_hosts; i++) {
+		if (!hosts[i])
+			continue;
+		for (j = 0; j < hosts[i]->alias_nr; j++) {
+			if (!prefixcmp(url, hosts[i]->alias[j])) {
+				char *ret = malloc(strlen(hosts[i]->base) -
+						   strlen(hosts[i]->alias[j]) +
+						   strlen(url) + 1);
+				strcpy(ret, hosts[i]->base);
+				strcat(ret, url + strlen(hosts[i]->alias[j]));
+				return ret;
+			}
+		}
+	}
+	return url;
+}
+
 static void add_push_refspec(struct remote *remote, const char *ref)
 {
 	int nr = remote->push_refspec_nr + 1;
@@ -41,6 +73,11 @@ static void add_url(struct remote *remote, const char *url)
 	remote->url_nr = nr;
 }
 
+static void add_url_alias(struct remote *remote, const char *url)
+{
+	add_url(remote, alias_url(url));
+}
+
 static struct remote *make_remote(const char *name, int len)
 {
 	int i, empty = -1;
@@ -121,6 +158,48 @@ static struct branch *make_branch(const char *name, int len)
 	return branches[empty];
 }
 
+static struct host *make_host(const char *name, int len)
+{
+	int i, empty = -1;
+
+	for (i = 0; i < allocated_hosts; i++) {
+		if (!hosts[i]) {
+			if (empty < 0)
+				empty = i;
+		} else {
+			if (len ? (!strncmp(name, hosts[i]->name, len) &&
+				   !hosts[i]->name[len]) :
+			    !strcmp(name, hosts[i]->name))
+				return hosts[i];
+		}
+	}
+
+	if (empty < 0) {
+		empty = allocated_hosts;
+		allocated_hosts += allocated_hosts ? allocated_hosts : 1;
+		hosts = xrealloc(hosts,
+				 sizeof(*hosts) * allocated_hosts);
+		memset(hosts + empty, 0,
+		       (allocated_hosts - empty) * sizeof(*hosts));
+	}
+	hosts[empty] = xcalloc(1, sizeof(struct host));
+	if (len)
+		hosts[empty]->name = xstrndup(name, len);
+	else
+		hosts[empty]->name = xstrdup(name);
+
+	return hosts[empty];
+}
+
+static void add_alias(struct host *host, const char *name)
+{
+	int nr = host->alias_nr + 1;
+	host->alias =
+		xrealloc(host->alias, nr * sizeof(char *));
+	host->alias[nr-1] = name;
+	host->alias_nr = nr;
+}
+
 static void read_remotes_file(struct remote *remote)
 {
 	FILE *f = fopen(git_path("remotes/%s", remote->name), "r");
@@ -154,7 +233,7 @@ static void read_remotes_file(struct remote *remote)
 
 		switch (value_list) {
 		case 0:
-			add_url(remote, xstrdup(s));
+			add_url_alias(remote, xstrdup(s));
 			break;
 		case 1:
 			add_push_refspec(remote, xstrdup(s));
@@ -206,7 +285,7 @@ static void read_branches_file(struct remote *remote)
 	} else {
 		branch = "refs/heads/master";
 	}
-	add_url(remote, p);
+	add_url_alias(remote, p);
 	add_fetch_refspec(remote, branch);
 	remote->fetch_tags = 1; /* always auto-follow */
 }
@@ -236,6 +315,20 @@ static int handle_config(const char *key, const char *value)
 		}
 		return 0;
 	}
+	if (!prefixcmp(key, "host.")) {
+		struct host *host;
+		name = key + 5;
+		subkey = strrchr(name, '.');
+		if (!subkey)
+			return 0;
+		host = make_host(name, subkey - name);
+		if (!value)
+			return 0;
+		if (!strcmp(subkey, ".base"))
+			host->base = xstrdup(value);
+		else if (!strcmp(subkey, ".rewritebase"))
+			add_alias(host, xstrdup(value));
+	}
 	if (prefixcmp(key,  "remote."))
 		return 0;
 	name = key + 7;
@@ -287,6 +380,18 @@ static int handle_config(const char *key, const char *value)
 	return 0;
 }
 
+static void alias_all_urls(void)
+{
+	int i, j;
+	for (i = 0; i < allocated_remotes; i++) {
+		if (!remotes[i])
+			continue;
+		for (j = 0; j < remotes[i]->url_nr; j++) {
+			remotes[i]->url[j] = alias_url(remotes[i]->url[j]);
+		}
+	}
+}
+
 static void read_config(void)
 {
 	unsigned char sha1[20];
@@ -303,6 +408,7 @@ static void read_config(void)
 			make_branch(head_ref + strlen("refs/heads/"), 0);
 	}
 	git_config(handle_config);
+	alias_all_urls();
 }
 
 struct refspec *parse_ref_spec(int nr_refspec, const char **refspec)
@@ -368,7 +474,7 @@ struct remote *remote_get(const char *name)
 			read_branches_file(ret);
 	}
 	if (!ret->url)
-		add_url(ret, name);
+		add_url_alias(ret, name);
 	if (!ret->url)
 		return NULL;
 	ret->fetch = parse_ref_spec(ret->fetch_refspec_nr, ret->fetch_refspec);
-- 
1.5.4.1.1350.g2b9ee

Re: [PATCH] Add support for host aliases in config files

[Jakub Narebski]

Daniel Barkalow <barkalow@iabervon.org> writes:

> +host.<name>.*::
> +	These options provide a way to rewrite URLs when there is a
> +	pattern of URLs with a common prefix which should be replaced
> +	with a different prefix. For every 'alias' prefix given, any

You menat 'rewritebase' prefix here, isn't it?

> +------------
> +	[host "<host>"]
> +		base = <actual url base>
> +		rewritebase = <other url base>
> +------------
[...]
> +		else if (!strcmp(subkey, ".rewritebase"))
> +			add_alias(host, xstrdup(value));
> +	}

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: [PATCH] Add support for host aliases in config files

[Daniel Barkalow]

On Sun, 17 Feb 2008, Jakub Narebski wrote:

> Daniel Barkalow <barkalow@iabervon.org> writes:
> 
> > +host.<name>.*::
> > +	These options provide a way to rewrite URLs when there is a
> > +	pattern of URLs with a common prefix which should be replaced
> > +	with a different prefix. For every 'alias' prefix given, any
> 
> You menat 'rewritebase' prefix here, isn't it?

Yes.

	-Daniel
*This .sig left intentionally blank*

Re: [PATCH] Add support for host aliases in config files

[Johannes Schindelin]

Hi,

On Sun, 17 Feb 2008, Daniel Barkalow wrote:

> This allows users with different preferences for access methods to the 
> same remote repositories to rewrite each other's URLs by pattern 
> matching across a large set of similiarly set up repositories to each 
> get the desired access.
> 
> Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>

How about adding your example with master.kernel.org?  That should make it 
easier to understand for people like me, who was puzzled after reading 
this commit message the first time.

Ciao,
Dscho

Re: [PATCH] Add support for host aliases in config files

[Junio C Hamano]

Daniel Barkalow <barkalow@iabervon.org> writes:

> ..., but I'd like to get the 
> code portion out there are reviewed, at least, since I think last time, 
> the patch only got as far as a discussion of how I should explain what it 
> does.

I actually think that is the most important part to get it right
first.  I usually do not have to read the patch text to reject
an ill-conceived idea if the description is unclear and/or
unconvincing.

I think the documentation (I removed from the quote) shows the
feature is unambiguously good.

> diff --git a/remote.c b/remote.c
> index 6b56473..59338a3 100644
> --- a/remote.c
> +++ b/remote.c
> @@ -2,6 +2,15 @@
>  #include "remote.h"
>  #include "refs.h"
>  
> +struct host {
> +	const char *name;
> +
> +	const char *base;
> +
> +	const char **alias;
> +	int alias_nr;
> +};

Extra blank lines?

> @@ -11,9 +20,32 @@ static int allocated_branches;
>  static struct branch *current_branch;
>  static const char *default_remote_name;
>  
> +static struct host **hosts;
> +static int allocated_hosts;

The allocation in remote.c file is unusual from the rest of git
that usually follow the technical/api-allocation-growing
convention (the comment unfortunately applies to the code we
already have there).

> +static const char *alias_url(const char *url)
> +{
> +	int i, j;
> +	for (i = 0; i < allocated_hosts; i++) {
> +		if (!hosts[i])
> +			continue;
> +		for (j = 0; j < hosts[i]->alias_nr; j++) {
> +			if (!prefixcmp(url, hosts[i]->alias[j])) {
> +				char *ret = malloc(strlen(hosts[i]->base) -
> +						   strlen(hosts[i]->alias[j]) +
> +						   strlen(url) + 1);
> +				strcpy(ret, hosts[i]->base);
> +				strcat(ret, url + strlen(hosts[i]->alias[j]));
> +				return ret;
> +			}

First match semantics is fine during runtime but at some point
we would want a "config file lint" that points out ambiguous
aliases perhaps?

> +static struct host *make_host(const char *name, int len)
> +{
> ...
> +	if (empty < 0) {
> +		empty = allocated_hosts;
> +		allocated_hosts += allocated_hosts ? allocated_hosts : 1;
> +		hosts = xrealloc(hosts,
> +				 sizeof(*hosts) * allocated_hosts);

This hand-rolled allocation growing is quite different from the
rest of our codebase.

> +static void add_alias(struct host *host, const char *name)
> +{
> +	int nr = host->alias_nr + 1;
> +	host->alias =
> +		xrealloc(host->alias, nr * sizeof(char *));
> +	host->alias[nr-1] = name;
> +	host->alias_nr = nr;
> +}

And this "add one-by-one" allocation, too.

> @@ -154,7 +233,7 @@ static void read_remotes_file(struct remote *remote)
>  
>  		switch (value_list) {
>  		case 0:
> -			add_url(remote, xstrdup(s));
> +			add_url_alias(remote, xstrdup(s));
>  			break;
>  		case 1:
>  			add_push_refspec(remote, xstrdup(s));
> @@ -206,7 +285,7 @@ static void read_branches_file(struct remote *remote)
>  	} else {
>  		branch = "refs/heads/master";
>  	}
> -	add_url(remote, p);
> +	add_url_alias(remote, p);
>  	add_fetch_refspec(remote, branch);
>  	remote->fetch_tags = 1; /* always auto-follow */
>  }

These two are logical and clean updates.

> @@ -236,6 +315,20 @@ static int handle_config(const char *key, const char *value)
>  		}
>  		return 0;
>  	}
> +	if (!prefixcmp(key, "host.")) {
> +		struct host *host;
> +		name = key + 5;
> +		subkey = strrchr(name, '.');
> +		if (!subkey)
> +			return 0;

This "ignore this entry" is good.  We might later want to add
host.<var> that is not about a specific host, and we would want
to be able to read a configuration that is written for such a
future version of git.

> +		host = make_host(name, subkey - name);
> +		if (!value)
> +			return 0;

This is not.

 (1) We should barf saying "host.<this-host>.<var> configuration
     should be a string", for base and rewritebase, instead of
     silently ignoring such a misconfiguration;

 (2) We should _not_ do such barfing for future variables that
     are not base nor rewritebase, so this "return" is at a
     wrong place.

So the code should do this part (perhaps with git_config_string())
first,...

> +		if (!strcmp(subkey, ".base"))
> +			host->base = xstrdup(value);
> +		else if (!strcmp(subkey, ".rewritebase"))
> +			add_alias(host, xstrdup(value));

... and then ignore anything other than host.<this-host>.{base,rewritebase}
that may mean something in future versions of git.

Re: [PATCH] Add support for host aliases in config files

[Daniel Barkalow]

On Sun, 17 Feb 2008, Junio C Hamano wrote:

> Daniel Barkalow <barkalow@iabervon.org> writes:
> 
> > ..., but I'd like to get the 
> > code portion out there are reviewed, at least, since I think last time, 
> > the patch only got as far as a discussion of how I should explain what it 
> > does.
> 
> I actually think that is the most important part to get it right
> first.  I usually do not have to read the patch text to reject
> an ill-conceived idea if the description is unclear and/or
> unconvincing.
> 
> I think the documentation (I removed from the quote) shows the
> feature is unambiguously good.

What I meant by that was that you'd asked for some change in how this 
feature would get mentioned to people reading man pages on git commands 
that can use it.

> > diff --git a/remote.c b/remote.c
> > index 6b56473..59338a3 100644
> > --- a/remote.c
> > +++ b/remote.c
> > @@ -2,6 +2,15 @@
> >  #include "remote.h"
> >  #include "refs.h"
> >  
> > +struct host {
> > +	const char *name;
> > +
> > +	const char *base;
> > +
> > +	const char **alias;
> > +	int alias_nr;
> > +};
> 
> Extra blank lines?

I tend to like grouping related fields by having blank lines between 
unrelated ones, but it's not needed here.

> > @@ -11,9 +20,32 @@ static int allocated_branches;
> >  static struct branch *current_branch;
> >  static const char *default_remote_name;
> >  
> > +static struct host **hosts;
> > +static int allocated_hosts;
> 
> The allocation in remote.c file is unusual from the rest of git
> that usually follow the technical/api-allocation-growing
> convention (the comment unfortunately applies to the code we
> already have there).

I think I originally used an older style that never got converted, and 
this time matched the style of the rest of the file. I'll add an initial 
patch to convert the rest of the file to the standard thing, and use that 
style for this patch as well.

> > +static const char *alias_url(const char *url)
> > +{
> > +	int i, j;
> > +	for (i = 0; i < allocated_hosts; i++) {
> > +		if (!hosts[i])
> > +			continue;
> > +		for (j = 0; j < hosts[i]->alias_nr; j++) {
> > +			if (!prefixcmp(url, hosts[i]->alias[j])) {
> > +				char *ret = malloc(strlen(hosts[i]->base) -
> > +						   strlen(hosts[i]->alias[j]) +
> > +						   strlen(url) + 1);
> > +				strcpy(ret, hosts[i]->base);
> > +				strcat(ret, url + strlen(hosts[i]->alias[j]));
> > +				return ret;
> > +			}
> 
> First match semantics is fine during runtime but at some point
> we would want a "config file lint" that points out ambiguous
> aliases perhaps?

I think first match may actually be useful in dealing with sites where a 
subset of the web-served space is git-served or something. But I'm really 
not sure; maybe we want "longest base" or something.

> > @@ -154,7 +233,7 @@ static void read_remotes_file(struct remote *remote)
> >  
> >  		switch (value_list) {
> >  		case 0:
> > -			add_url(remote, xstrdup(s));
> > +			add_url_alias(remote, xstrdup(s));
> >  			break;
> >  		case 1:
> >  			add_push_refspec(remote, xstrdup(s));
> > @@ -206,7 +285,7 @@ static void read_branches_file(struct remote *remote)
> >  	} else {
> >  		branch = "refs/heads/master";
> >  	}
> > -	add_url(remote, p);
> > +	add_url_alias(remote, p);
> >  	add_fetch_refspec(remote, branch);
> >  	remote->fetch_tags = 1; /* always auto-follow */
> >  }
> 
> These two are logical and clean updates.
> 
> > @@ -236,6 +315,20 @@ static int handle_config(const char *key, const char *value)
> >  		}
> >  		return 0;
> >  	}
> > +	if (!prefixcmp(key, "host.")) {
> > +		struct host *host;
> > +		name = key + 5;
> > +		subkey = strrchr(name, '.');
> > +		if (!subkey)
> > +			return 0;
> 
> This "ignore this entry" is good.  We might later want to add
> host.<var> that is not about a specific host, and we would want
> to be able to read a configuration that is written for such a
> future version of git.
> 
> > +		host = make_host(name, subkey - name);
> > +		if (!value)
> > +			return 0;
> 
> This is not.
> 
>  (1) We should barf saying "host.<this-host>.<var> configuration
>      should be a string", for base and rewritebase, instead of
>      silently ignoring such a misconfiguration;

True. I'll look up the present best practices for config stuff.

>  (2) We should _not_ do such barfing for future variables that
>      are not base nor rewritebase, so this "return" is at a
>      wrong place.

I was intentionally careful to ignore unknown options.

	-Daniel
*This .sig left intentionally blank*

[PATCH] Add support for host aliases in config files

[Daniel Barkalow]

This allows users with different preferences for access methods to the
same remote repositories to rewrite each other's URLs to get the
desired access.

Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
 Documentation/config.txt |   15 ++++++
 remote.c                 |  112 ++++++++++++++++++++++++++++++++++++++++++++-
 2 files changed, 124 insertions(+), 3 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 877eda9..dae79ce 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -596,6 +596,21 @@ help.format::
 	Values 'man', 'info', 'web' and 'html' are supported. 'man' is
 	the default. 'web' and 'html' are the same.
 
+host.<name>.base::
+	The base URL which should be used for this particular
+	host. This can be used by a user who has a better access
+	method to a repository than other users to make use of the
+	preferable path despite getting URLs from other users using
+	more commonly-available methods. Alternatively, a user who
+	only has less privileged access to a repository than the usual
+	audience can use this mechanism to replace disallowed methods
+	with public ones.
+
+host.<name>.alias::
+	Additional base URLs which refer to this host. If a URL
+	matches this, any access to it will use the URL formed with
+	the corresponding base URL instead of the given URL.
+
 http.proxy::
 	Override the HTTP proxy, normally configured using the 'http_proxy'
 	environment variable (see linkgit:curl[1]).  This can be overridden
diff --git a/remote.c b/remote.c
index 0e00680..76ed576 100644
--- a/remote.c
+++ b/remote.c
@@ -2,6 +2,15 @@
 #include "remote.h"
 #include "refs.h"
 
+struct host {
+	const char *name;
+
+	const char *base;
+
+	const char **alias;
+	int alias_nr;
+};
+
 static struct remote **remotes;
 static int allocated_remotes;
 
@@ -11,9 +20,32 @@ static int allocated_branches;
 static struct branch *current_branch;
 static const char *default_remote_name;
 
+static struct host **hosts;
+static int allocated_hosts;
+
 #define BUF_SIZE (2048)
 static char buffer[BUF_SIZE];
 
+static const char *alias_url(const char *url)
+{
+	int i, j;
+	for (i = 0; i < allocated_hosts; i++) {
+		if (!hosts[i])
+			continue;
+		for (j = 0; j < hosts[i]->alias_nr; j++) {
+			if (!prefixcmp(url, hosts[i]->alias[j])) {
+				char *ret = malloc(strlen(hosts[i]->base) -
+						   strlen(hosts[i]->alias[j]) +
+						   strlen(url) + 1);
+				strcpy(ret, hosts[i]->base);
+				strcat(ret, url + strlen(hosts[i]->alias[j]));
+				return ret;
+			}
+		}
+	}
+	return url;
+}
+
 static void add_push_refspec(struct remote *remote, const char *ref)
 {
 	int nr = remote->push_refspec_nr + 1;
@@ -41,6 +73,11 @@ static void add_url(struct remote *remote, const char *url)
 	remote->url_nr = nr;
 }
 
+static void add_url_alias(struct remote *remote, const char *url)
+{
+	add_url(remote, alias_url(url));
+}
+
 static struct remote *make_remote(const char *name, int len)
 {
 	int i, empty = -1;
@@ -121,6 +158,48 @@ static struct branch *make_branch(const char *name, int len)
 	return branches[empty];
 }
 
+static struct host *make_host(const char *name, int len)
+{
+	int i, empty = -1;
+
+	for (i = 0; i < allocated_hosts; i++) {
+		if (!hosts[i]) {
+			if (empty < 0)
+				empty = i;
+		} else {
+			if (len ? (!strncmp(name, hosts[i]->name, len) &&
+				   !hosts[i]->name[len]) :
+			    !strcmp(name, hosts[i]->name))
+				return hosts[i];
+		}
+	}
+
+	if (empty < 0) {
+		empty = allocated_hosts;
+		allocated_hosts += allocated_hosts ? allocated_hosts : 1;
+		hosts = xrealloc(hosts,
+				 sizeof(*hosts) * allocated_hosts);
+		memset(hosts + empty, 0,
+		       (allocated_hosts - empty) * sizeof(*hosts));
+	}
+	hosts[empty] = xcalloc(1, sizeof(struct host));
+	if (len)
+		hosts[empty]->name = xstrndup(name, len);
+	else
+		hosts[empty]->name = xstrdup(name);
+
+	return hosts[empty];
+}
+
+static void add_alias(struct host *host, const char *name)
+{
+	int nr = host->alias_nr + 1;
+	host->alias =
+		xrealloc(host->alias, nr * sizeof(char *));
+	host->alias[nr-1] = name;
+	host->alias_nr = nr;
+}
+
 static void read_remotes_file(struct remote *remote)
 {
 	FILE *f = fopen(git_path("remotes/%s", remote->name), "r");
@@ -154,7 +233,7 @@ static void read_remotes_file(struct remote *remote)
 
 		switch (value_list) {
 		case 0:
-			add_url(remote, xstrdup(s));
+			add_url_alias(remote, xstrdup(s));
 			break;
 		case 1:
 			add_push_refspec(remote, xstrdup(s));
@@ -206,7 +285,7 @@ static void read_branches_file(struct remote *remote)
 	} else {
 		branch = "refs/heads/master";
 	}
-	add_url(remote, p);
+	add_url_alias(remote, p);
 	add_fetch_refspec(remote, branch);
 	remote->fetch_tags = 1; /* always auto-follow */
 }
@@ -233,6 +312,20 @@ static int handle_config(const char *key, const char *value)
 			add_merge(branch, xstrdup(value));
 		return 0;
 	}
+	if (!prefixcmp(key, "host.")) {
+		struct host *host;
+		name = key + 5;
+		subkey = strrchr(name, '.');
+		if (!subkey)
+			return 0;
+		host = make_host(name, subkey - name);
+		if (!value)
+			return 0;
+		if (!strcmp(subkey, ".base"))
+			host->base = xstrdup(value);
+	        else if (!strcmp(subkey, ".alias"))
+			add_alias(host, xstrdup(value));
+	}
 	if (prefixcmp(key,  "remote."))
 		return 0;
 	name = key + 7;
@@ -284,6 +377,18 @@ static int handle_config(const char *key, const char *value)
 	return 0;
 }
 
+static void alias_all_urls(void)
+{
+	int i, j;
+	for (i = 0; i < allocated_remotes; i++) {
+		if (!remotes[i])
+			continue;
+		for (j = 0; j < remotes[i]->url_nr; j++) {
+			remotes[i]->url[j] = alias_url(remotes[i]->url[j]);
+		}
+	}
+}
+
 static void read_config(void)
 {
 	unsigned char sha1[20];
@@ -300,6 +405,7 @@ static void read_config(void)
 			make_branch(head_ref + strlen("refs/heads/"), 0);
 	}
 	git_config(handle_config);
+	alias_all_urls();
 }
 
 struct refspec *parse_ref_spec(int nr_refspec, const char **refspec)
@@ -355,7 +461,7 @@ struct remote *remote_get(const char *name)
 			read_branches_file(ret);
 	}
 	if (!ret->url)
-		add_url(ret, name);
+		add_url_alias(ret, name);
 	if (!ret->url)
 		return NULL;
 	ret->fetch = parse_ref_spec(ret->fetch_refspec_nr, ret->fetch_refspec);
-- 
1.5.4.rc3.4.g16335

Re: [PATCH] Add support for host aliases in config files

[Jakub Narebski]

Daniel Barkalow <barkalow@iabervon.org> writes:

> This allows users with different preferences for access methods to the
> same remote repositories to rewrite each other's URLs to get the
> desired access.

[...]
> +host.<name>.base::
> +	The base URL which should be used for this particular
> +	host. This can be used by a user who has a better access
> +	method to a repository than other users to make use of the
> +	preferable path despite getting URLs from other users using
> +	more commonly-available methods. Alternatively, a user who
> +	only has less privileged access to a repository than the usual
> +	audience can use this mechanism to replace disallowed methods
> +	with public ones.
> +
> +host.<name>.alias::
> +	Additional base URLs which refer to this host. If a URL
> +	matches this, any access to it will use the URL formed with
> +	the corresponding base URL instead of the given URL.
> +

>From this I could not get how those configuration are meant to be
used. Perhaps some usage example?

BTW. wouldn't the same be solved better by enabling remote.<name>.url
to be multi-valued, first working for fetch, all URLs for push?

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: [PATCH] Add support for host aliases in config files

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> From this I could not get how those configuration are meant to be
> used. Perhaps some usage example?
>
> BTW. wouldn't the same be solved better by enabling remote.<name>.url
> to be multi-valued, first working for fetch, all URLs for push?

I think that is already the case.  "git-remote" currently has an
annoying bug I haven't bothered to look into that makes the
command complain when remote.$nick.url has more than one values.
Worse, it complains _twice_ (or N-1 times for a remote that has
N URLs).

        : gitster git.git/master; git remote
        Warning: more than one remote.builders.url
        Warning: more than one remote.builders.url
        builders
        gfi
        git-gui
        gitk
        git-p4
        git-svn
        jbf-um
        ko
        ko-private
        mingw
        origin
        repo
        spearce.git
        wing-fc5
        wing-fc7
        wing-fc8

Here, "builders" remote has 3 URLs because I wanted to use it to
push to 3 machines on which I build binary releases.

Re: [PATCH] Add support for host aliases in config files

[Daniel Barkalow]

On Fri, 25 Jan 2008, Jakub Narebski wrote:

> Daniel Barkalow <barkalow@iabervon.org> writes:
> 
> > This allows users with different preferences for access methods to the
> > same remote repositories to rewrite each other's URLs to get the
> > desired access.
> 
> [...]
> > +host.<name>.base::
> > +	The base URL which should be used for this particular
> > +	host. This can be used by a user who has a better access
> > +	method to a repository than other users to make use of the
> > +	preferable path despite getting URLs from other users using
> > +	more commonly-available methods. Alternatively, a user who
> > +	only has less privileged access to a repository than the usual
> > +	audience can use this mechanism to replace disallowed methods
> > +	with public ones.
> > +
> > +host.<name>.alias::
> > +	Additional base URLs which refer to this host. If a URL
> > +	matches this, any access to it will use the URL formed with
> > +	the corresponding base URL instead of the given URL.
> > +
> 
> From this I could not get how those configuration are meant to be
> used. Perhaps some usage example?

[host "kernel"]
        base = git://git.kernel.org/pub/
        alias = git+ssh://master.kernel.org/pub/
	alias = master.kernel.org:/pub/

> BTW. wouldn't the same be solved better by enabling remote.<name>.url
> to be multi-valued, first working for fetch, all URLs for push?

The real point is actually for when you're dealing with URLs on the 
command line which you've cut-and-paste from email or other things. For 
example, the patches in the -mm quilt series say where the git trees are, 
but they're all like 
"git+ssh://master.kernel.org/pub/scm/linux/kernel/git/dtor/input.git", 
which is ideal for people (like Andrew) who have accounts on master, but 
requires manual fixing for people (like me) who don't.

With the above config, I can do:

git fetch git+ssh://master.kernel.org/pub/scm/linux/kernel/git/dtor/input.git

and it actually fetches

git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git, which 
actually works for me.

	-Daniel
*This .sig left intentionally blank*

Re: [PATCH] Add support for host aliases in config files

[Jakub Narebski]

On Friday, 25 January 2008, Daniel Barkalow wrote:
> On Fri, 25 Jan 2008, Jakub Narebski wrote:
>> Daniel Barkalow <barkalow@iabervon.org> writes:
>> 
>>> This allows users with different preferences for access methods to the
>>> same remote repositories to rewrite each other's URLs to get the
>>> desired access.
>> 
>> [...]
>>> +host.<name>.base::
>>> +	The base URL which should be used for this particular
>>> +	host. This can be used by a user who has a better access
>>> +	method to a repository than other users to make use of the
>>> +	preferable path despite getting URLs from other users using
>>> +	more commonly-available methods. Alternatively, a user who
>>> +	only has less privileged access to a repository than the usual
>>> +	audience can use this mechanism to replace disallowed methods
>>> +	with public ones.
>>> +
>>> +host.<name>.alias::
>>> +	Additional base URLs which refer to this host. If a URL
>>> +	matches this, any access to it will use the URL formed with
>>> +	the corresponding base URL instead of the given URL.
>>> +
>> 
>> From this I could not get how those configuration are meant to be
>> used. Perhaps some usage example?
> 
> [host "kernel"]
>         base = git://git.kernel.org/pub/
>         alias = git+ssh://master.kernel.org/pub/
>         alias = master.kernel.org:/pub/
> 
>> BTW. wouldn't the same be solved better by enabling remote.<name>.url
>> to be multi-valued, first working for fetch, all URLs for push?

Ah, thanks. I have misunderstood the above description (hint, hint!)...
 
> The real point is actually for when you're dealing with URLs on the 
> command line which you've cut-and-paste from email or other things. For 
> example, the patches in the -mm quilt series say where the git trees are, 
> but they're all like 
> "git+ssh://master.kernel.org/pub/scm/linux/kernel/git/dtor/input.git", 
> which is ideal for people (like Andrew) who have accounts on master, but 
> requires manual fixing for people (like me) who don't.
> 
> With the above config, I can do:
> 
> git fetch git+ssh://master.kernel.org/pub/scm/linux/kernel/git/dtor/input.git

Couldn't you just configure "kernel" remote, and use "git fetch kernel"
instead?

> and it actually fetches
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git
>
> which actually works for me.

So this config variable is actually about _rewriting_ URLs, rather than
having multiple _alternate_ URLs to fetch from. IMHO either the
documentation above should be (re)written better (there is time, as we
are in feature freeze), or the example mentioned above should be added
(but where?).

-- 
Jakub Narebski
Poland

Re: [PATCH] Add support for host aliases in config files

[Daniel Barkalow]

On Fri, 25 Jan 2008, Jakub Narebski wrote:

> On Friday, 25 January 2008, Daniel Barkalow wrote:
> > On Fri, 25 Jan 2008, Jakub Narebski wrote:
> >> Daniel Barkalow <barkalow@iabervon.org> writes:
> >> 
> >>> This allows users with different preferences for access methods to the
> >>> same remote repositories to rewrite each other's URLs to get the
> >>> desired access.
> >> 
> >> [...]
> >>> +host.<name>.base::
> >>> +	The base URL which should be used for this particular
> >>> +	host. This can be used by a user who has a better access
> >>> +	method to a repository than other users to make use of the
> >>> +	preferable path despite getting URLs from other users using
> >>> +	more commonly-available methods. Alternatively, a user who
> >>> +	only has less privileged access to a repository than the usual
> >>> +	audience can use this mechanism to replace disallowed methods
> >>> +	with public ones.
> >>> +
> >>> +host.<name>.alias::
> >>> +	Additional base URLs which refer to this host. If a URL
> >>> +	matches this, any access to it will use the URL formed with
> >>> +	the corresponding base URL instead of the given URL.
> >>> +
> >> 
> >> From this I could not get how those configuration are meant to be
> >> used. Perhaps some usage example?
> > 
> > [host "kernel"]
> >         base = git://git.kernel.org/pub/
> >         alias = git+ssh://master.kernel.org/pub/
> >         alias = master.kernel.org:/pub/
> > 
> >> BTW. wouldn't the same be solved better by enabling remote.<name>.url
> >> to be multi-valued, first working for fetch, all URLs for push?
> 
> Ah, thanks. I have misunderstood the above description (hint, hint!)...

Yup, that's why I need to talk it through. It made perfect sense to me, 
but I'd had the problem in the first place and wrote the code...

> > The real point is actually for when you're dealing with URLs on the 
> > command line which you've cut-and-paste from email or other things. For 
> > example, the patches in the -mm quilt series say where the git trees are, 
> > but they're all like 
> > "git+ssh://master.kernel.org/pub/scm/linux/kernel/git/dtor/input.git", 
> > which is ideal for people (like Andrew) who have accounts on master, but 
> > requires manual fixing for people (like me) who don't.
> > 
> > With the above config, I can do:
> > 
> > git fetch git+ssh://master.kernel.org/pub/scm/linux/kernel/git/dtor/input.git
> 
> Couldn't you just configure "kernel" remote, and use "git fetch kernel"
> instead?

Note the .../dtor/input.git at the end. There are another 50-odd different 
URLs in -mm that start git+ssh://master.kernel.org/pub/ where I have to 
use git://git.kernel.org/pub/ instead, and it's not a fixed set.

> > and it actually fetches
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git
> >
> > which actually works for me.
> 
> So this config variable is actually about _rewriting_ URLs, rather than
> having multiple _alternate_ URLs to fetch from. IMHO either the
> documentation above should be (re)written better (there is time, as we
> are in feature freeze), or the example mentioned above should be added
> (but where?).

Maybe we should have a "host.<name>.*" section that explains the 
collection of configuration options as a group? Like:

----------
host.<name>.*::
	These options provide a way to rewrite URLs when there is a
	pattern of URLs with a common prefix which should be replaced
	with a different prefix. For every 'alias' prefix given, any
	URL git receives that starts with that prefix will be
	rewritten to have the 'base' prefix instead. In cases where
	some site serves a large number of repositories, and serves
	them with multiple access methods, and some users need to use
	different access methods, this feature allows people to
	specify any of the equivalent URLs and have git automatically
	rewrite the URL to the best alternative for the particular
	user, even for a never-before-seen repository on the site.

host.<name>.base::
	The base URL which should be used for this particular
	host.

host.<name>.alias::
	Additional base URLs which refer to this host. If a URL
	matches this, any access to it will use the URL formed with
	the corresponding base URL instead of the given URL.
----------

	-Daniel
*This .sig left intentionally blank*

Re: [PATCH] Add support for host aliases in config files

[Jakub Narebski]

On Fri, 25 Jan 2008, Daniel Barkalow wrote:
> On Fri, 25 Jan 2008, Jakub Narebski wrote:
> 
>>
>> So this config variable is actually about _rewriting_ URLs, rather than
>> having multiple _alternate_ URLs to fetch from. IMHO either the
>> documentation above should be (re)written better (there is time, as we
>> are in feature freeze), or the example mentioned above should be added
>> (but where?).
> 
> Maybe we should have a "host.<name>.*" section that explains the 
> collection of configuration options as a group? Like:
> 
> ----------
> host.<name>.*::
> 	These options provide a way to rewrite URLs when there is a
> 	pattern of URLs with a common prefix which should be replaced
> 	with a different prefix. For every 'alias' prefix given, any
> 	URL git receives that starts with that prefix will be
> 	rewritten to have the 'base' prefix instead. In cases where
> 	some site serves a large number of repositories, and serves
> 	them with multiple access methods, and some users need to use
> 	different access methods, this feature allows people to
> 	specify any of the equivalent URLs and have git automatically
> 	rewrite the URL to the best alternative for the particular
> 	user, even for a never-before-seen repository on the site.
> 
> host.<name>.base::
> 	The base URL which should be used for this particular
> 	host.
> 
> host.<name>.alias::
> 	Additional base URLs which refer to this host. If a URL
> 	matches this, any access to it will use the URL formed with
> 	the corresponding base URL instead of the given URL.

Good idea. IMVHO it reads better than previous version. Together with
explanation and example usage in Documentation/urls.txt (or somewhere
else) it would be enough and easy to understand.

BTW. shouldn't it be rather host.<name>.rewritebase (a la mod_rewrite)?
I think it is better name for this configuration variable.

-- 
Jakub Narebski
Poland

Re: [PATCH] Add support for host aliases in config files

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> So this config variable is actually about _rewriting_ URLs, rather than
> having multiple _alternate_ URLs to fetch from. IMHO either the
> documentation above should be (re)written better (there is time, as we
> are in feature freeze), or the example mentioned above should be added
> (but where?).

I think Documentation/urls.txt would be a good candidate.
Currently it talks only about non-nicknamed remotes, and is
included only in clone and remote.  This makes sense as their
usage of urls.txt documentation is to talk about non-nicknamed
forms only (obviously clone cannot talk about nicknames in a
local repository that does not yet exist, and "remote add" needs
a non-nicknamed form as well).

Documentation/urls.txt can be enhanced to say that once you have
the remote.*.url and other configs, you can use its nickname to
name a remote repository.  Then it would become a good enough
shape to be included in push/fetch/pull pages as well.

Re: [PATCH] Add support for host aliases in config files

[Daniel Barkalow]

On Fri, 25 Jan 2008, Junio C Hamano wrote:

> Jakub Narebski <jnareb@gmail.com> writes:
> 
> > So this config variable is actually about _rewriting_ URLs, rather than
> > having multiple _alternate_ URLs to fetch from. IMHO either the
> > documentation above should be (re)written better (there is time, as we
> > are in feature freeze), or the example mentioned above should be added
> > (but where?).
> 
> I think Documentation/urls.txt would be a good candidate.
> Currently it talks only about non-nicknamed remotes, and is
> included only in clone and remote.  This makes sense as their
> usage of urls.txt documentation is to talk about non-nicknamed
> forms only (obviously clone cannot talk about nicknames in a
> local repository that does not yet exist, and "remote add" needs
> a non-nicknamed form as well).
> 
> Documentation/urls.txt can be enhanced to say that once you have
> the remote.*.url and other configs, you can use its nickname to
> name a remote repository.  Then it would become a good enough
> shape to be included in push/fetch/pull pages as well.

Isn't that Documentation/urls-remotes.txt?

In any case, this is a different nicknaming mechanism, because remotes are 
nicknames for repositories, and this is nicknames for collections of 
similarly-named repositories. (E.g., all the different publicly-accessible 
repositories on kernel.org)

So, something like:

diff --git a/Documentation/urls.txt b/Documentation/urls.txt
index 81ac17f..f47b9e0 100644
--- a/Documentation/urls.txt
+++ b/Documentation/urls.txt
@@ -36,6 +36,29 @@ To sync with a local directory, you can use:
 - file:///path/to/repo.git/
 ===============================================================
 
+If there are a large number of similarly-named remote repositories and
+you want to use a different format for them (such that the URLs you
+use will be rewritten into URLs that work), you can create a
+configuration section of the form:
+
+------------
+	[host "<host>"]
+		base = <actual url base>
+		alias = <other url base>
+------------
+
+In particular, if you need to use URLs like
+git://git.host.xz/repo.git, and you're getting a lot of URLs like
+host.xz:/path/to/repo.git/, or you'd like to use a URL like
+"work:repo.git" you can use a section:
+
+------------
+	[host "host.xz"]
+		base = git://git.host.xz/
+		alias = host.xz:/path/to/
+		alias = work:
+------------
+
 ifndef::git-clone[]
 They are mostly equivalent, except when cloning.  See
 linkgit:git-clone[1] for details.

	-Daniel
*This .sig left intentionally blank*

Re: [PATCH] Add support for host aliases in config files

[Jakub Narebski]

Daniel Barkalow wrote:

> So, something like:
> 
> diff --git a/Documentation/urls.txt b/Documentation/urls.txt
> index 81ac17f..f47b9e0 100644
> --- a/Documentation/urls.txt
> +++ b/Documentation/urls.txt
> @@ -36,6 +36,29 @@ To sync with a local directory, you can use:
>  - file:///path/to/repo.git/
>  ===============================================================
>  
> +If there are a large number of similarly-named remote repositories and
> +you want to use a different format for them (such that the URLs you
> +use will be rewritten into URLs that work), you can create a
> +configuration section of the form:
> +
> +------------
> +	[host "<host>"]
> +		base = <actual url base>
> +		alias = <other url base>
> +------------
> +
> +In particular, if you need to use URLs like
> +git://git.host.xz/repo.git, and you're getting a lot of URLs like
> +host.xz:/path/to/repo.git/, or you'd like to use a URL like
> +"work:repo.git" you can use a section:
> +
> +------------
> +	[host "host.xz"]
> +		base = git://git.host.xz/
> +		alias = host.xz:/path/to/
> +		alias = work:
> +------------
> +

Could you _finish_ that documentation with finished example of command
line example, which gets its URL rewritten? It stops a bit suddenly.

-- 
Jakub Narebski
Poland