[PATCH 2/2] Add support for url aliases in config files

[PATCH 2/2] Add support for url 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.

For example, if you don't have a kernel.org account, you might want
settings like:

[url "git://git.kernel.org/pub/"]
      aka = master.kernel.org:/pub

Then, if you give git a URL like:

  master.kernel.org:/pub/scm/linux/kernel/git/linville/wireless-2.6.git

it will act like you gave it:

  git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git

and you can cut-and-paste pull requests in email without fixing them
by hand, for example.

Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
The previous version of [PATCH 1/2] doesn't need any changes.

This version has the replacement base in the key, as discussed, and makes 
the whole thing about urls instead of hosts (so everything is renamed).

I also added some tests, which are a little bit lame in the particular 
context of the test setup. Also, using git-config to set options with 
complicated keys is a bit awkward. Perhaps it should have support for a 
command line like:

git config --set remote "This is my remote" url http://example.com/repo

 Documentation/config.txt |   16 ++++++++
 Documentation/urls.txt   |   23 +++++++++++
 remote.c                 |   97 ++++++++++++++++++++++++++++++++++++++++++++-
 t/t5516-fetch-push.sh    |   31 +++++++++++++++
 4 files changed, 164 insertions(+), 3 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index f2f6a77..44f4c4b 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -646,6 +646,11 @@ help.format::
 	Values 'man', 'info', 'web' and 'html' are supported. 'man' is
 	the default. 'web' and 'html' are the same.
 
+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
@@ -886,6 +891,17 @@ tar.umask::
 	archiving user's umask will be used instead.  See umask(2) and
 	linkgit:git-archive[1].
 
+url.<base>.aka::
+	Any URL that starts with this value will be rewritten to
+	start, instead, with <base>. 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. The effect of
+	having multiple aka values match is undefined.
+
 user.email::
 	Your email address to be recorded in any newly created commits.
 	Can be overridden by the 'GIT_AUTHOR_EMAIL', 'GIT_COMMITTER_EMAIL', and
diff --git a/Documentation/urls.txt b/Documentation/urls.txt
index 81ac17f..0115af7 100644
--- a/Documentation/urls.txt
+++ b/Documentation/urls.txt
@@ -44,3 +44,26 @@ 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:
+
+------------
+	[url "<actual url base>"]
+		aka = <other url base>
+------------
+
+If you have a section:
+
+------------
+	[host "git://git.host.xz/"]
+		aka = host.xz:/path/to/
+		aka = 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 457d8a4..f8ee38e 100644
--- a/remote.c
+++ b/remote.c
@@ -2,6 +2,13 @@
 #include "remote.h"
 #include "refs.h"
 
+struct rewrite {
+	const char *base;
+	const char **aka;
+	int aka_nr;
+	int aka_alloc;
+};
+
 static struct remote **remotes;
 static int remotes_alloc;
 static int remotes_nr;
@@ -13,9 +20,33 @@ static int branches_nr;
 static struct branch *current_branch;
 static const char *default_remote_name;
 
+static struct rewrite **rewrite;
+static int rewrite_alloc;
+static int rewrite_nr;
+
 #define BUF_SIZE (2048)
 static char buffer[BUF_SIZE];
 
+static const char *alias_url(const char *url)
+{
+	int i, j;
+	for (i = 0; i < rewrite_nr; i++) {
+		if (!rewrite[i])
+			continue;
+		for (j = 0; j < rewrite[i]->aka_nr; j++) {
+			if (!prefixcmp(url, rewrite[i]->aka[j])) {
+				char *ret = malloc(strlen(rewrite[i]->base) -
+						   strlen(rewrite[i]->aka[j]) +
+						   strlen(url) + 1);
+				strcpy(ret, rewrite[i]->base);
+				strcat(ret, url + strlen(rewrite[i]->aka[j]));
+				return ret;
+			}
+		}
+	}
+	return url;
+}
+
 static void add_push_refspec(struct remote *remote, const char *ref)
 {
 	ALLOC_GROW(remote->push_refspec,
@@ -38,6 +69,11 @@ static void add_url(struct remote *remote, const char *url)
 	remote->url[remote->url_nr++] = url;
 }
 
+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)
 {
 	struct remote *ret;
@@ -95,6 +131,35 @@ static struct branch *make_branch(const char *name, int len)
 	return ret;
 }
 
+static struct rewrite *make_rewrite(const char *base, int len)
+{
+	struct rewrite *ret;
+	int i;
+
+	for (i = 0; i < rewrite_nr; i++) {
+		if (len ? (!strncmp(base, rewrite[i]->base, len) &&
+			   !rewrite[i]->base[len]) :
+		    !strcmp(base, rewrite[i]->base))
+			return rewrite[i];
+	}
+
+	ALLOC_GROW(rewrite, rewrite_nr + 1, rewrite_alloc);
+	ret = xcalloc(1, sizeof(struct rewrite));
+	rewrite[rewrite_nr++] = ret;
+	if (len)
+		ret->base = xstrndup(base, len);
+	else
+		ret->base = xstrdup(base);
+
+	return ret;
+}
+
+static void add_aka(struct rewrite *rewrite, const char *aka)
+{
+	ALLOC_GROW(rewrite->aka, rewrite->aka_nr + 1, rewrite->aka_alloc);
+	rewrite->aka[rewrite->aka_nr++] = aka;
+}
+
 static void read_remotes_file(struct remote *remote)
 {
 	FILE *f = fopen(git_path("remotes/%s", remote->name), "r");
@@ -128,7 +193,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));
@@ -180,7 +245,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 */
 }
@@ -210,6 +275,19 @@ static int handle_config(const char *key, const char *value)
 		}
 		return 0;
 	}
+	if (!prefixcmp(key, "url.")) {
+		struct rewrite *rewrite;
+		name = key + 5;
+		subkey = strrchr(name, '.');
+		if (!subkey)
+			return 0;
+		rewrite = make_rewrite(name, subkey - name);
+		if (!strcmp(subkey, ".aka")) {
+			if (!value)
+				return config_error_nonbool(key);
+			add_aka(rewrite, xstrdup(value));
+		}
+	}
 	if (prefixcmp(key,  "remote."))
 		return 0;
 	name = key + 7;
@@ -261,6 +339,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 < remotes_nr; 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];
@@ -277,6 +367,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)
@@ -342,7 +433,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);
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index 9d2dc33..4ffe2a1 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -100,6 +100,23 @@ test_expect_success 'fetch with wildcard' '
 	)
 '
 
+test_expect_success 'fetch with aka' '
+	mk_empty &&
+	(
+		TRASH=$(pwd) &&
+		cd testrepo &&
+		git config url./$TRASH/.aka trash/
+		git config remote.up.url trash/. &&
+		git config remote.up.fetch "refs/heads/*:refs/remotes/origin/*" &&
+		git fetch up &&
+
+		r=$(git show-ref -s --verify refs/remotes/origin/master) &&
+		test "z$r" = "z$the_commit" &&
+
+		test 1 = $(git for-each-ref refs/remotes/origin | wc -l)
+	)
+'
+
 test_expect_success 'push without wildcard' '
 	mk_empty &&
 
@@ -126,6 +143,20 @@ test_expect_success 'push with wildcard' '
 	)
 '
 
+test_expect_success 'push with aka' '
+	mk_empty &&
+	TRASH=$(pwd) &&
+	git config url./$TRASH/.aka trash/ &&
+	git push trash/testrepo refs/heads/master:refs/remotes/origin/master &&
+	(
+		cd testrepo &&
+		r=$(git show-ref -s --verify refs/remotes/origin/master) &&
+		test "z$r" = "z$the_commit" &&
+
+		test 1 = $(git for-each-ref refs/remotes/origin | wc -l)
+	)
+'
+
 test_expect_success 'push with matching heads' '
 
 	mk_test heads/master &&
-- 
1.5.4.1.1350.g2b9ee

Re: [PATCH 2/2] Add support for url aliases in config files

[Junio C Hamano]

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 by pattern
> matching across a large set of similiarly set up repositories to each
> get the desired access.
>
> For example, if you don't have a kernel.org account, you might want
> settings like:
>
> [url "git://git.kernel.org/pub/"]
>       aka = master.kernel.org:/pub
>
> Then, if you give git a URL like:
>
>   master.kernel.org:/pub/scm/linux/kernel/git/linville/wireless-2.6.git
>
> it will act like you gave it:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
>
> and you can cut-and-paste pull requests in email without fixing them
> by hand, for example.

To me, "url.$this_is_what_I_use.aka = $how_they_might_call_it"
initially felt backwards, but the point of the facility is to
allow mapping many ways other people might call it to how you
would (and the other way would not make sense as allowing to map
one thing to multiple is only to introduce unnecessary
ambiguity), so it makes perfect sense.

> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index f2f6a77..44f4c4b 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -646,6 +646,11 @@ help.format::
>  	Values 'man', 'info', 'web' and 'html' are supported. 'man' is
>  	the default. 'web' and 'html' are the same.
>  
> +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.
> +

This still stands???

> diff --git a/Documentation/urls.txt b/Documentation/urls.txt
> index 81ac17f..0115af7 100644
> --- a/Documentation/urls.txt
> +++ b/Documentation/urls.txt
> @@ -44,3 +44,26 @@ endif::git-clone[]
> ...
> +If you have a section:
> +
> +------------
> +	[host "git://git.host.xz/"]
> +		aka = host.xz:/path/to/
> +		aka = 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".

This still stands???

Re: [PATCH 2/2] Add support for url aliases in config files

[Daniel Barkalow]

On Wed, 20 Feb 2008, Junio C Hamano 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 by pattern
> > matching across a large set of similiarly set up repositories to each
> > get the desired access.
> >
> > For example, if you don't have a kernel.org account, you might want
> > settings like:
> >
> > [url "git://git.kernel.org/pub/"]
> >       aka = master.kernel.org:/pub
> >
> > Then, if you give git a URL like:
> >
> >   master.kernel.org:/pub/scm/linux/kernel/git/linville/wireless-2.6.git
> >
> > it will act like you gave it:
> >
> >   git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
> >
> > and you can cut-and-paste pull requests in email without fixing them
> > by hand, for example.
> 
> To me, "url.$this_is_what_I_use.aka = $how_they_might_call_it"
> initially felt backwards, but the point of the facility is to
> allow mapping many ways other people might call it to how you
> would (and the other way would not make sense as allowing to map
> one thing to multiple is only to introduce unnecessary
> ambiguity), so it makes perfect sense.

This order of values is definitely the right thing, for the mapping 
reasons you saw. And I think "aka" is generally used to indicate 
additional non-canonical names for something with an official name (see, 
for example, IMDB's usage). I haven't been able to come up with anything 
better to indicate "this is a name that I will recognize but not use 
myself".

> > diff --git a/Documentation/config.txt b/Documentation/config.txt
> > index f2f6a77..44f4c4b 100644
> > --- a/Documentation/config.txt
> > +++ b/Documentation/config.txt
> > @@ -646,6 +646,11 @@ help.format::
> >  	Values 'man', 'info', 'web' and 'html' are supported. 'man' is
> >  	the default. 'web' and 'html' are the same.
> >  
> > +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.
> > +
> 
> This still stands???

Oops, didn't quite remove all of it.

> > diff --git a/Documentation/urls.txt b/Documentation/urls.txt
> > index 81ac17f..0115af7 100644
> > --- a/Documentation/urls.txt
> > +++ b/Documentation/urls.txt
> > @@ -44,3 +44,26 @@ endif::git-clone[]
> > ...
> > +If you have a section:
> > +
> > +------------
> > +	[host "git://git.host.xz/"]
> > +		aka = host.xz:/path/to/
> > +		aka = 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".
> 
> This still stands???

And missed the "host"->"url" bit while I fixed the rest of the example. 
Want a replacement, or can you make the obvious corrections just as 
easily yourself?

	-Daniel
*This .sig left intentionally blank*

Re: [PATCH 2/2] Add support for url aliases in config files

[Junio C Hamano]

Daniel Barkalow <barkalow@iabervon.org> writes:

> On Wed, 20 Feb 2008, Junio C Hamano wrote:
> ...
>> To me, "url.$this_is_what_I_use.aka = $how_they_might_call_it"
>> initially felt backwards, but the point of the facility is to
>> allow mapping many ways other people might call it to how you
>> would (and the other way would not make sense as allowing to map
>> one thing to multiple is only to introduce unnecessary
>> ambiguity), so it makes perfect sense.
>
> This order of values is definitely the right thing, for the mapping 
> reasons you saw. And I think "aka" is generally used to indicate 
> additional non-canonical names for something with an official name (see, 
> for example, IMDB's usage). I haven't been able to come up with anything 
> better to indicate "this is a name that I will recognize but not use 
> myself".

Yeah, that "aka" is still disturbing.

	[url A]
        	aka = B

would read to me: "A is also known as B" but that is clearly not
what it means here.  You would want this:

	[url A]
        	aka = B 
		aka = C

to mean "B is also known as A.  C is also known as A."  IOW, you
are using it backwards, because their name is more official and
you are using your own unofficial name to call it.

Sorry, but I cannot think of a better way to resolve this, other
than by spelling the keyword backwards, but that still makes it
"aka".

>> > diff --git a/Documentation/urls.txt b/Documentation/urls.txt
>> > index 81ac17f..0115af7 100644
>> > --- a/Documentation/urls.txt
>> > +++ b/Documentation/urls.txt
>> > @@ -44,3 +44,26 @@ endif::git-clone[]
>> > ...
>> > +If you have a section:
>> > +
>> > +------------
>> > +	[host "git://git.host.xz/"]
>> > +		aka = host.xz:/path/to/
>> > +		aka = 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".
>> 
>> This still stands???
>
> And missed the "host"->"url" bit while I fixed the rest of the example. 

So this part is not wanted, right?

> Want a replacement, or can you make the obvious corrections just as 
> easily yourself?

If my above rant about "aka" is not a total misunderstanding,
I'd rather see somebody (could be you, or others on the list) to
come up with a better keyword and have a replacement patch based
on it.

Re: [PATCH 2/2] Add support for url aliases in config files

[Jay Soffian]

On Feb 20, 2008 2:24 PM, Daniel Barkalow <barkalow@iabervon.org> wrote:
> This order of values is definitely the right thing, for the mapping
> reasons you saw. And I think "aka" is generally used to indicate
> additional non-canonical names for something with an official name (see,
> for example, IMDB's usage). I haven't been able to come up with anything
> better to indicate "this is a name that I will recognize but not use
> myself".

I think the word you want is "alias", isn't it? I've never really seen
aka used in a technical sense, whereas alias is used quite often (URL
aliases, DNS aliases, etc). So:

url.$canonical_name.alias = $local_name.

$0.02.

j.

Re: [PATCH 2/2] Add support for url aliases in config files

[Jay Soffian]

On Feb 20, 2008 2:42 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Yeah, that "aka" is still disturbing.
>
>         [url A]
>                 aka = B
>
> would read to me: "A is also known as B" but that is clearly not
> what it means here.  You would want this:
>
>         [url A]
>                 aka = B
>                 aka = C
>
> to mean "B is also known as A.  C is also known as A."  IOW, you
> are using it backwards, because their name is more official and
> you are using your own unofficial name to call it.
>
> Sorry, but I cannot think of a better way to resolve this, other
> than by spelling the keyword backwards, but that still makes it
> "aka".

I dunno, I find this eminently clear:

        [url A]
                alias = B
                alias = C

B and C are aliases for A. How else could you read that?

j.

Re: [PATCH 2/2] Add support for url aliases in config files

[Junio C Hamano]

"Jay Soffian" <jaysoffian@gmail.com> writes:

> On Feb 20, 2008 2:24 PM, Daniel Barkalow <barkalow@iabervon.org> wrote:
>> This order of values is definitely the right thing, for the mapping
>> reasons you saw. And I think "aka" is generally used to indicate
>> additional non-canonical names for something with an official name (see,
>> for example, IMDB's usage). I haven't been able to come up with anything
>> better to indicate "this is a name that I will recognize but not use
>> myself".
>
> I think the word you want is "alias", isn't it? I've never really seen
> aka used in a technical sense, whereas alias is used quite often (URL
> aliases, DNS aliases, etc). So:
>
> url.$canonical_name.alias = $local_name.

Read the first line you quoted, and think again.

Re: [PATCH 2/2] Add support for url aliases in config files

[Jay Soffian]

On Feb 20, 2008 2:58 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> "Jay Soffian" <jaysoffian@gmail.com> writes:
>
> > On Feb 20, 2008 2:24 PM, Daniel Barkalow <barkalow@iabervon.org> wrote:
> >> This order of values is definitely the right thing, for the mapping
> >> reasons you saw. And I think "aka" is generally used to indicate
> >> additional non-canonical names for something with an official name (see,
> >> for example, IMDB's usage). I haven't been able to come up with anything
> >> better to indicate "this is a name that I will recognize but not use
> >> myself".
> >
> > I think the word you want is "alias", isn't it? I've never really seen
> > aka used in a technical sense, whereas alias is used quite often (URL
> > aliases, DNS aliases, etc). So:
> >
> > url.$canonical_name.alias = $local_name.
>
> Read the first line you quoted, and think again.

Well I'm just not seeing it, but you could you do it just like the
[alias] section?

git config url.local canonical

[url]
  local = canonical

git config would have to be extended to deal with a URL on the LHS.


?

Re: [PATCH 2/2] Add support for url aliases in config files

[Daniel Barkalow]

On Wed, 20 Feb 2008, Junio C Hamano wrote:

> Daniel Barkalow <barkalow@iabervon.org> writes:
> 
> > On Wed, 20 Feb 2008, Junio C Hamano wrote:
> > ...
> >> To me, "url.$this_is_what_I_use.aka = $how_they_might_call_it"
> >> initially felt backwards, but the point of the facility is to
> >> allow mapping many ways other people might call it to how you
> >> would (and the other way would not make sense as allowing to map
> >> one thing to multiple is only to introduce unnecessary
> >> ambiguity), so it makes perfect sense.
> >
> > This order of values is definitely the right thing, for the mapping 
> > reasons you saw. And I think "aka" is generally used to indicate 
> > additional non-canonical names for something with an official name (see, 
> > for example, IMDB's usage). I haven't been able to come up with anything 
> > better to indicate "this is a name that I will recognize but not use 
> > myself".
> 
> Yeah, that "aka" is still disturbing.
> 
> 	[url A]
>         	aka = B
> 
> would read to me: "A is also known as B" but that is clearly not
> what it means here. 

But it is; the thing which we will call "A" is also known (and 
sometimes called by other people, or us speaking informally) as "B".

> You would want this:
> 
> 	[url A]
>         	aka = B 
> 		aka = C
> 
> to mean "B is also known as A.  C is also known as A."  IOW, you
> are using it backwards, because their name is more official and
> you are using your own unofficial name to call it.

No, "A" is the *real* name, the one that actually works. B and C are 
pseudonyms, of which there may be multiple, both from more "official" (but 
git is decentralized, and doesn't care for officialness) and less official 
sources.

I think you're seeing this feature as taking "correct" URLs and rewriting 
them to be local aliases, when the only thing that makes sense for a 
system like git is really to say that whatever URL works for us is 
"correct", and everybody else is speaking their own local dialect.

In fact, one case I anticipate using extensively is:

[url "git://iabervon.org/~barkalow/"]
	aka = ":"

Such that, once clone is using remote.{c,h}, "git clone :git" would clone 
my home git repository. Obviously ":" isn't the real name in this 
rewriting.

> >> > diff --git a/Documentation/urls.txt b/Documentation/urls.txt
> >> > index 81ac17f..0115af7 100644
> >> > --- a/Documentation/urls.txt
> >> > +++ b/Documentation/urls.txt
> >> > @@ -44,3 +44,26 @@ endif::git-clone[]
> >> > ...
> >> > +If you have a section:
> >> > +
> >> > +------------
> >> > +	[host "git://git.host.xz/"]
> >> > +		aka = host.xz:/path/to/
> >> > +		aka = 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".
> >> 
> >> This still stands???
> >
> > And missed the "host"->"url" bit while I fixed the rest of the example. 
> 
> So this part is not wanted, right?

The first part (not quoted) is not wanted (it was left over from when I 
combined the three entries into one and moved it under 'u' instead of 
'h'). This part *is* wanted, but should say:

+	[url "git://git.host.xz/"]

instead of

+	[host "git://git.host.xz/"]

since I changed the option name.

	-Daniel
*This .sig left intentionally blank*

Re: [PATCH 2/2] Add support for url aliases in config files

[しらいしななこ]

Quoting Junio C Hamano <gitster@pobox.com>:

> Yeah, that "aka" is still disturbing.
>
> 	[url A]
>         	aka = B
>
> would read to me: "A is also known as B" but that is clearly not
> what it means here.  You would want this:
>
> 	[url A]
>         	aka = B 
> 		aka = C
>
> to mean "B is also known as A.  C is also known as A."  IOW, you
> are using it backwards, because their name is more official and
> you are using your own unofficial name to call it.
>
> Sorry, but I cannot think of a better way to resolve this, other
> than by spelling the keyword backwards, but that still makes it
> "aka".

Isn't what you mean to say "A stands for B and C"?

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

----------------------------------------------------------------------
Find out how you can get spam free email.
http://www.bluebottle.com/tag/3

Re: [PATCH 2/2] Add support for url aliases in config files

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 982 bytes --]

Hi,

On Thu, 21 Feb 2008, しらいしななこ wrote:

> Quoting Junio C Hamano <gitster@pobox.com>:
> 
> > Yeah, that "aka" is still disturbing.
> >
> > 	[url A]
> >         	aka = B
> >
> > would read to me: "A is also known as B" but that is clearly not
> > what it means here.  You would want this:
> >
> > 	[url A]
> >         	aka = B 
> > 		aka = C
> >
> > to mean "B is also known as A.  C is also known as A."  IOW, you
> > are using it backwards, because their name is more official and
> > you are using your own unofficial name to call it.
> >
> > Sorry, but I cannot think of a better way to resolve this, other
> > than by spelling the keyword backwards, but that still makes it
> > "aka".
> 
> Isn't what you mean to say "A stands for B and C"?

So you mean

[url A]
	standsFor = B
	standsFor = C

? ;-)

This might be seen as bike-shedding by some, but I think that it is 
actually worthwhile to kick back and forth some ideas, and pick the best 
one.

Ciao,
Dscho

Re: [PATCH 2/2] Add support for url aliases in config files

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> So you mean
>
> [url A]
> 	standsFor = B
> 	standsFor = C
>
> ? ;-)
>
> This might be seen as bike-shedding by some, but I think that it is 
> actually worthwhile to kick back and forth some ideas, and pick the best 
> one.

It appears that Daniel and I disagree which one we should
consider canonical and which one substitute.  I tend to think
what you would see in the mailing list announce (B and C) are
canonical and you rewrite them to adjust to your local needs
(A).  But Daniel has a point that to the environment that needs
to access the repository as A, that name is the canonical one.

I am not very much interested in resolving which one is which.

In either case, I think a good approach to take is to find a
wording that conveys the notion "I will use A to mean what some
other people might call B or C" unambiguously.

When you have the above in $HOME/.gitconfig, it would mean 
"To me, A stands for B or C".  If you have it in .git/config of
the project, you are saying "When pushing/fetching in this
repository, A stands for B or C".  I think that is a reasonable
way to express what we want.

Re: [PATCH 2/2] Add support for url aliases in config files

[Jay Soffian]

On Wed, Feb 20, 2008 at 7:47 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
>  In either case, I think a good approach to take is to find a
>  wording that conveys the notion "I will use A to mean what some
>  other people might call B or C" unambiguously.

[url A]
  other_people_call_it = B
  other_people_call_it = C

[local_url A]
  external_url = B
  external_url = C
j.

Re: [PATCH 2/2] Add support for url aliases in config files

[Linus Torvalds]

On Wed, 20 Feb 2008, Jay Soffian wrote:

> On Wed, Feb 20, 2008 at 7:47 PM, Junio C Hamano <gitster@pobox.com> wrote:
> >
> >  In either case, I think a good approach to take is to find a
> >  wording that conveys the notion "I will use A to mean what some
> >  other people might call B or C" unambiguously.
> 
> [url A]
>   other_people_call_it = B
>   other_people_call_it = C
> 
> [local_url A]
>   external_url = B
>   external_url = C

Well, realistically, what's really the use of this?

The only really sane use of this is the one that Daniel started out with: 
you may have a "external" representation of a name, but for your own 
purely local configuration reasons, you may want to map that name into 
another one that works for you.

The reason may be some local protocol issue: let's say that you see all 
these pointers to git://git.kernel.org/ flying around, because that is the 
official home of the git repository itself, but you work at a company that 
has a firewall that doesn't let git through. So you want to still *use* 
those names that other people use, but you want to remap them through some 
proxy server (or a local cache), or just to use ssh instead.

So it's generally *not* that it's an "alias" for another site, since it 
isn't that in general - it may just be a very local configuration thing. 
It's also not really that you would call it one thing and others would 
call it another thing: you want to call it the *same* thing as others call 
it, but you want to work around some specific site issue (or just use a 
cache that is closer without having to think about it).

So I think it really boils down to the fact that you want to "rewrite" the 
thing. Not aliases, not "also known as", but you're logically really 
looking for something like 

	[access "git://git.kernel.org/*"]
		proxy = proxy-program
		url = "ssh://master.kernel.org/*"

which admittedly looks rather strange too, but at the same time it does 
make sense from a "what do we really want to do?" standpoint.

Of course, in this case Daniel didn't actually do that "proxy" part, but I 
think the argument that we should try to make the config file syntax 
describe what the user wants to do is still very true. So skip that 
"proxy" part (maybe somebody wants to do that too some day), and leave the 

	[access "original"]
		url = "rewritten"

kind of syntax.

(And no, I'm not at all married to the "access" and "url" parts - I don't 
care. I'm just saying that syntax should be tied to what people want to 
do, not anything else.

				Linus

Re: [PATCH 2/2] Add support for url aliases in config files

[Jay Soffian]

On Wed, Feb 20, 2008 at 8:47 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:

>  So I think it really boils down to the fact that you want to "rewrite" the
>  thing. Not aliases, not "also known as", but you're logically really
>  looking for something like
>
>         [access "git://git.kernel.org/*"]
>                 proxy = proxy-program
>                 url = "ssh://master.kernel.org/*"
>
>  which admittedly looks rather strange too, but at the same time it does
>  make sense from a "what do we really want to do?" standpoint.
>
>  Of course, in this case Daniel didn't actually do that "proxy" part, but I
>  think the argument that we should try to make the config file syntax
>  describe what the user wants to do is still very true. So skip that
>  "proxy" part (maybe somebody wants to do that too some day), and leave the
>
>         [access "original"]
>                 url = "rewritten"
>
>  kind of syntax.
>
>  (And no, I'm not at all married to the "access" and "url" parts - I don't
>  care. I'm just saying that syntax should be tied to what people want to
>  do, not anything else.

Shrug:

[core]
  rewriterule = <from> <to>
  ; ...

If <from> or <to> contain whitespace then you have to use %20 or quotes.

(There is already proxy support elsewhere in the config.)

I think I'm done suggesting paint colors. :-)

j.

Re: [PATCH 2/2] Add support for url aliases in config files

[Daniel Barkalow]

On Wed, 20 Feb 2008, Linus Torvalds wrote:

> On Wed, 20 Feb 2008, Jay Soffian wrote:
> 
> > On Wed, Feb 20, 2008 at 7:47 PM, Junio C Hamano <gitster@pobox.com> wrote:
> > >
> > >  In either case, I think a good approach to take is to find a
> > >  wording that conveys the notion "I will use A to mean what some
> > >  other people might call B or C" unambiguously.
> > 
> > [url A]
> >   other_people_call_it = B
> >   other_people_call_it = C
> > 
> > [local_url A]
> >   external_url = B
> >   external_url = C
> 
> Well, realistically, what's really the use of this?
> 
> The only really sane use of this is the one that Daniel started out with: 
> you may have a "external" representation of a name, but for your own 
> purely local configuration reasons, you may want to map that name into 
> another one that works for you.
> 
> The reason may be some local protocol issue: let's say that you see all 
> these pointers to git://git.kernel.org/ flying around, because that is the 
> official home of the git repository itself, but you work at a company that 
> has a firewall that doesn't let git through. So you want to still *use* 
> those names that other people use, but you want to remap them through some 
> proxy server (or a local cache), or just to use ssh instead.
> 
> So it's generally *not* that it's an "alias" for another site, since it 
> isn't that in general - it may just be a very local configuration thing. 
> It's also not really that you would call it one thing and others would 
> call it another thing: you want to call it the *same* thing as others call 
> it, but you want to work around some specific site issue (or just use a 
> cache that is closer without having to think about it).
> 
> So I think it really boils down to the fact that you want to "rewrite" the 
> thing. Not aliases, not "also known as", but you're logically really 
> looking for something like 
> 
> 	[access "git://git.kernel.org/*"]
> 		proxy = proxy-program
> 		url = "ssh://master.kernel.org/*"
> 
> which admittedly looks rather strange too, but at the same time it does 
> make sense from a "what do we really want to do?" standpoint.
> 
> Of course, in this case Daniel didn't actually do that "proxy" part, but I 
> think the argument that we should try to make the config file syntax 
> describe what the user wants to do is still very true. So skip that 
> "proxy" part (maybe somebody wants to do that too some day), and leave the 
> 
> 	[access "original"]
> 		url = "rewritten"
> 
> kind of syntax.

I think it has to be:

	[something "rewritten"]
		something = "original"
		something = "other original"

Because you want to be able to take multiple "original"s for the same 
result in order to avoid duplicating that part (and leading to skew if you 
decide to change). But I like the idea of basing the naming on the 
rewriting operation rather than the relationship. Maybe:

[url "rewritten"]
	insteadOf = "original"

	-Daniel
*This .sig left intentionally blank*

Re: [PATCH 2/2] Add support for url aliases in config files

[Junio C Hamano]

Daniel Barkalow <barkalow@iabervon.org> writes:

> [url "rewritten"]
> 	insteadOf = "original"

That's much clearer than anything I've seen in this thread which
one is the one you cannot use yourself and which one is what you
have to use to get it to work.

Re: [PATCH 2/2] Add support for url aliases in config files

[Jon Loeliger]

Linus Torvalds wrote:
> 
> The only really sane use of this is the one that Daniel started out with: 
> you may have a "external" representation of a name, but for your own 
> purely local configuration reasons, you may want to map that name into 
> another one that works for you.
> 

[ snip ]

> So it's generally *not* that it's an "alias" for another site, since it 
> isn't that in general - it may just be a very local configuration thing. 
> It's also not really that you would call it one thing and others would 
> call it another thing: you want to call it the *same* thing as others call 
> it, but you want to work around some specific site issue (or just use a 
> cache that is closer without having to think about it).

I totally agree with all that.

> 	[access "git://git.kernel.org/*"]
> 		proxy = proxy-program
> 		url = "ssh://master.kernel.org/*"
> 
> which admittedly looks rather strange too, but at the same time it does 
> make sense from a "what do we really want to do?" standpoint.
> 
> Of course, in this case Daniel didn't actually do that "proxy" part, but I 
> think the argument that we should try to make the config file syntax 
> describe what the user wants to do is still very true. So skip that 
> "proxy" part (maybe somebody wants to do that too some day), and leave the 
> 
> 	[access "original"]
> 		url = "rewritten"
> 
> kind of syntax.
> 
> (And no, I'm not at all married to the "access" and "url" parts - I don't 
> care. I'm just saying that syntax should be tied to what people want to 
> do, not anything else.

Right.  And I think part of the issue is, which of the two forms will
be present in the user's git requests?  He'd _like_ to use the same,
canonical name everyone else does, but for whatever reason, it has to
be rewritten for the actual transportation implementation to work.
Sort of like virtual/physical address definitions here?

    [virtual_url "git://git.kernel.org/"]
        physical_url = "ssh://master.kernel.org/"

But maybe it needs to be:

    physical_url ["ssh://master.kernel.org/"]
        virtual_url = "git://git.kernel.org/"
        virtual_url = "git://kernel.org/"

The git user would use the virtual_url, but it would be translated
to the physical_url for the underlying implementation to work.

I think it is more than paint coloring at work here.  The important
part is to convey the concepts properly with the names.  The reader
of the config file has to be able to tell which way the mapping is run.

jdl

Re: [PATCH 2/2] Add support for url aliases in config files

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Daniel Barkalow <barkalow@iabervon.org> writes:
>
>> [url "rewritten"]
>> 	insteadOf = "original"
>
> That's much clearer than anything I've seen in this thread which
> one is the one you cannot use yourself and which one is what you
> have to use to get it to work.

Although I am willing to step in when they need help, I usually
try not to finish up other people's patches, especially when I
know they are capable.

But I wanted to take 'next' into a shape as close to the -rc1 as
possible early, so here is my stab at it.  This will be in 'next'
tonight.

The patch is relative to your:

    Date: Wed, 20 Feb 2008 13:43:53 -0500 (EST)
    Subject: [PATCH 2/2] Add support for url aliases in config files
    Message-ID: <alpine.LNX.1.00.0802201337060.19024@iabervon.org>

aka

    http://article.gmane.org/gmane.comp.version-control.git/74535

based on the earlier discussions.

 * The first hunk to Documentation/config.txt which was a
   leftover from the previous round is dropped.

 * Fixed s/host/url/ in Documentation/config.txt, which was also
   a leftover from the previous round.

 * The result is undefined if you have this:

	[url "foo"]
        	insteadOf = "baz"
	[url "bar"]
        	insteadOf = "baz"

   I tried to clarify the handling of this misconfiguration by
   rewording, but I do not know how successful I was.

 * s/aka/insteadOf/ everywhere.

---

 Documentation/config.txt |   10 +++-------
 Documentation/urls.txt   |   14 +++++++-------
 remote.c                 |   24 ++++++++++++------------
 t/t5516-fetch-push.sh    |    8 ++++----
 4 files changed, 26 insertions(+), 30 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 44f4c4b..2981389 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -646,11 +646,6 @@ help.format::
 	Values 'man', 'info', 'web' and 'html' are supported. 'man' is
 	the default. 'web' and 'html' are the same.
 
-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
@@ -891,7 +886,7 @@ tar.umask::
 	archiving user's umask will be used instead.  See umask(2) and
 	linkgit:git-archive[1].
 
-url.<base>.aka::
+url.<base>.insteadOf::
 	Any URL that starts with this value will be rewritten to
 	start, instead, with <base>. In cases where some site serves a
 	large number of repositories, and serves them with multiple
@@ -900,7 +895,8 @@ url.<base>.aka::
 	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. The effect of
-	having multiple aka values match is undefined.
+	having multiple `insteadOf` values from different
+	`<base>` match to an URL is undefined.
 
 user.email::
 	Your email address to be recorded in any newly created commits.
diff --git a/Documentation/urls.txt b/Documentation/urls.txt
index 0115af7..fa34c67 100644
--- a/Documentation/urls.txt
+++ b/Documentation/urls.txt
@@ -53,17 +53,17 @@ configuration section of the form:
 
 ------------
 	[url "<actual url base>"]
-		aka = <other url base>
+		insteadOf = <other url base>
 ------------
 
-If you have a section:
+For example, with this:
 
 ------------
-	[host "git://git.host.xz/"]
-		aka = host.xz:/path/to/
-		aka = work:
+	[url "git://git.host.xz/"]
+		insteadOf = host.xz:/path/to/
+		insteadOf = 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".
+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 f8ee38e..0012954 100644
--- a/remote.c
+++ b/remote.c
@@ -4,9 +4,9 @@
 
 struct rewrite {
 	const char *base;
-	const char **aka;
-	int aka_nr;
-	int aka_alloc;
+	const char **instead_of;
+	int instead_of_nr;
+	int instead_of_alloc;
 };
 
 static struct remote **remotes;
@@ -33,13 +33,13 @@ static const char *alias_url(const char *url)
 	for (i = 0; i < rewrite_nr; i++) {
 		if (!rewrite[i])
 			continue;
-		for (j = 0; j < rewrite[i]->aka_nr; j++) {
-			if (!prefixcmp(url, rewrite[i]->aka[j])) {
+		for (j = 0; j < rewrite[i]->instead_of_nr; j++) {
+			if (!prefixcmp(url, rewrite[i]->instead_of[j])) {
 				char *ret = malloc(strlen(rewrite[i]->base) -
-						   strlen(rewrite[i]->aka[j]) +
+						   strlen(rewrite[i]->instead_of[j]) +
 						   strlen(url) + 1);
 				strcpy(ret, rewrite[i]->base);
-				strcat(ret, url + strlen(rewrite[i]->aka[j]));
+				strcat(ret, url + strlen(rewrite[i]->instead_of[j]));
 				return ret;
 			}
 		}
@@ -154,10 +154,10 @@ static struct rewrite *make_rewrite(const char *base, int len)
 	return ret;
 }
 
-static void add_aka(struct rewrite *rewrite, const char *aka)
+static void add_instead_of(struct rewrite *rewrite, const char *instead_of)
 {
-	ALLOC_GROW(rewrite->aka, rewrite->aka_nr + 1, rewrite->aka_alloc);
-	rewrite->aka[rewrite->aka_nr++] = aka;
+	ALLOC_GROW(rewrite->instead_of, rewrite->instead_of_nr + 1, rewrite->instead_of_alloc);
+	rewrite->instead_of[rewrite->instead_of_nr++] = instead_of;
 }
 
 static void read_remotes_file(struct remote *remote)
@@ -282,10 +282,10 @@ static int handle_config(const char *key, const char *value)
 		if (!subkey)
 			return 0;
 		rewrite = make_rewrite(name, subkey - name);
-		if (!strcmp(subkey, ".aka")) {
+		if (!strcmp(subkey, ".insteadof")) {
 			if (!value)
 				return config_error_nonbool(key);
-			add_aka(rewrite, xstrdup(value));
+			add_instead_of(rewrite, xstrdup(value));
 		}
 	}
 	if (prefixcmp(key,  "remote."))
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index 4ffe2a1..9023ba0 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -100,12 +100,12 @@ test_expect_success 'fetch with wildcard' '
 	)
 '
 
-test_expect_success 'fetch with aka' '
+test_expect_success 'fetch with insteadOf' '
 	mk_empty &&
 	(
 		TRASH=$(pwd) &&
 		cd testrepo &&
-		git config url./$TRASH/.aka trash/
+		git config url./$TRASH/.insteadOf trash/
 		git config remote.up.url trash/. &&
 		git config remote.up.fetch "refs/heads/*:refs/remotes/origin/*" &&
 		git fetch up &&
@@ -143,10 +143,10 @@ test_expect_success 'push with wildcard' '
 	)
 '
 
-test_expect_success 'push with aka' '
+test_expect_success 'push with insteadOf' '
 	mk_empty &&
 	TRASH=$(pwd) &&
-	git config url./$TRASH/.aka trash/ &&
+	git config url./$TRASH/.insteadOf trash/ &&
 	git push trash/testrepo refs/heads/master:refs/remotes/origin/master &&
 	(
 		cd testrepo &&

Re: [PATCH 2/2] Add support for url aliases in config files

[Daniel Barkalow]

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

> Junio C Hamano <gitster@pobox.com> writes:
> 
> > Daniel Barkalow <barkalow@iabervon.org> writes:
> >
> >> [url "rewritten"]
> >> 	insteadOf = "original"
> >
> > That's much clearer than anything I've seen in this thread which
> > one is the one you cannot use yourself and which one is what you
> > have to use to get it to work.
> 
> Although I am willing to step in when they need help, I usually
> try not to finish up other people's patches, especially when I
> know they are capable.
> 
> But I wanted to take 'next' into a shape as close to the -rc1 as
> possible early, so here is my stab at it.  This will be in 'next'
> tonight.

Thanks; that's exactly what I would have done (assuming I didn't miss 
places like last time). Except that it should say that it's still 
undefined if you use:

        [url "foo"]
                insteadOf = "baz"
        [url "bar"]
                insteadOf = "baz/sub"

in that you can't predict whether "baz/sub/a" will be "bar/a" or 
"foo/sub/a". This is actually what I'm most concerned about, since there 
is actually a logical expectation (the one that matches more will be used 
in preference to the less specific one), but that's not implemented. 
Someday, we'll probably want to implement it, and that'll change the 
behavior of this particular case.

	-Daniel
*This .sig left intentionally blank*

Re: [PATCH 2/2] Add support for url aliases in config files

[Junio C Hamano]

Daniel Barkalow <barkalow@iabervon.org> writes:

> Thanks; that's exactly what I would have done (assuming I didn't miss 
> places like last time). Except that it should say that it's still 
> undefined if you use:
>
>         [url "foo"]
>                 insteadOf = "baz"
>         [url "bar"]
>                 insteadOf = "baz/sub"
>
> in that you can't predict whether "baz/sub/a" will be "bar/a" or 
> "foo/sub/a". This is actually what I'm most concerned about, since there 
> is actually a logical expectation (the one that matches more will be used 
> in preference to the less specific one), but that's not implemented. 
> Someday, we'll probably want to implement it, and that'll change the 
> behavior of this particular case.

I'd say that that is a reasonable expectation, and it would be
fair to say that if we have it, the topic will be in 1.5.5 and
otherwise it won't.

This might be a bit over-engineered, but should do the job.

---
 Documentation/config.txt |    5 +--
 remote.c                 |   54 ++++++++++++++++++++++++++++++++-------------
 2 files changed, 40 insertions(+), 19 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 2981389..57b9b99 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -894,9 +894,8 @@ url.<base>.insteadOf::
 	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. The effect of
-	having multiple `insteadOf` values from different
-	`<base>` match to an URL is undefined.
+	never-before-seen repository on the site.  When more than one
+	insteadOf strings match a given URL, the longest match is used.
 
 user.email::
 	Your email address to be recorded in any newly created commits.
diff --git a/remote.c b/remote.c
index 0012954..1f83696 100644
--- a/remote.c
+++ b/remote.c
@@ -2,9 +2,14 @@
 #include "remote.h"
 #include "refs.h"
 
+struct counted_string {
+	size_t len;
+	const char *s;
+};
 struct rewrite {
 	const char *base;
-	const char **instead_of;
+	size_t baselen;
+	struct counted_string *instead_of;
 	int instead_of_nr;
 	int instead_of_alloc;
 };
@@ -30,21 +35,32 @@ static char buffer[BUF_SIZE];
 static const char *alias_url(const char *url)
 {
 	int i, j;
+	char *ret;
+	struct counted_string *longest;
+	int longest_i;
+
+	longest = NULL;
+	longest_i = -1;
 	for (i = 0; i < rewrite_nr; i++) {
 		if (!rewrite[i])
 			continue;
 		for (j = 0; j < rewrite[i]->instead_of_nr; j++) {
-			if (!prefixcmp(url, rewrite[i]->instead_of[j])) {
-				char *ret = malloc(strlen(rewrite[i]->base) -
-						   strlen(rewrite[i]->instead_of[j]) +
-						   strlen(url) + 1);
-				strcpy(ret, rewrite[i]->base);
-				strcat(ret, url + strlen(rewrite[i]->instead_of[j]));
-				return ret;
+			if (!prefixcmp(url, rewrite[i]->instead_of[j].s) &&
+			    (!longest ||
+			     longest->len < rewrite[i]->instead_of[j].len)) {
+				longest = &(rewrite[i]->instead_of[j]);
+				longest_i = i;
 			}
 		}
 	}
-	return url;
+	if (!longest)
+		return url;
+
+	ret = malloc(rewrite[longest_i]->baselen +
+		     (strlen(url) - longest->len) + 1);
+	strcpy(ret, rewrite[longest_i]->base);
+	strcpy(ret + rewrite[longest_i]->baselen, url + longest->len);
+	return ret;
 }
 
 static void add_push_refspec(struct remote *remote, const char *ref)
@@ -137,27 +153,33 @@ static struct rewrite *make_rewrite(const char *base, int len)
 	int i;
 
 	for (i = 0; i < rewrite_nr; i++) {
-		if (len ? (!strncmp(base, rewrite[i]->base, len) &&
-			   !rewrite[i]->base[len]) :
-		    !strcmp(base, rewrite[i]->base))
+		if (len
+		    ? (len == rewrite[i]->baselen &&
+		       !strncmp(base, rewrite[i]->base, len))
+		    : !strcmp(base, rewrite[i]->base))
 			return rewrite[i];
 	}
 
 	ALLOC_GROW(rewrite, rewrite_nr + 1, rewrite_alloc);
 	ret = xcalloc(1, sizeof(struct rewrite));
 	rewrite[rewrite_nr++] = ret;
-	if (len)
+	if (len) {
 		ret->base = xstrndup(base, len);
-	else
+		ret->baselen = len;
+	}
+	else {
 		ret->base = xstrdup(base);
-
+		ret->baselen = strlen(base);
+	}
 	return ret;
 }
 
 static void add_instead_of(struct rewrite *rewrite, const char *instead_of)
 {
 	ALLOC_GROW(rewrite->instead_of, rewrite->instead_of_nr + 1, rewrite->instead_of_alloc);
-	rewrite->instead_of[rewrite->instead_of_nr++] = instead_of;
+	rewrite->instead_of[rewrite->instead_of_nr].s = instead_of;
+	rewrite->instead_of[rewrite->instead_of_nr].len = strlen(instead_of);
+	rewrite->instead_of_nr++;
 }
 
 static void read_remotes_file(struct remote *remote)

Re: [PATCH 2/2] Add support for url aliases in config files

[Daniel Barkalow]

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

> Daniel Barkalow <barkalow@iabervon.org> writes:
> 
> > Thanks; that's exactly what I would have done (assuming I didn't miss 
> > places like last time). Except that it should say that it's still 
> > undefined if you use:
> >
> >         [url "foo"]
> >                 insteadOf = "baz"
> >         [url "bar"]
> >                 insteadOf = "baz/sub"
> >
> > in that you can't predict whether "baz/sub/a" will be "bar/a" or 
> > "foo/sub/a". This is actually what I'm most concerned about, since there 
> > is actually a logical expectation (the one that matches more will be used 
> > in preference to the less specific one), but that's not implemented. 
> > Someday, we'll probably want to implement it, and that'll change the 
> > behavior of this particular case.
> 
> I'd say that that is a reasonable expectation, and it would be
> fair to say that if we have it, the topic will be in 1.5.5 and
> otherwise it won't.
> 
> This might be a bit over-engineered, but should do the job.

Very nice. And if we've got your over-engineered prefix-replacement code 
here, maybe I'll use it to also do the prefix-replacement for refspec 
patterns.

Acked-by: Daniel Barkalow <barkalow@iabervon.org>

	-Daniel
*This .sig left intentionally blank*