threads / patch / 12220

patch, 2 partsAdd support for url aliases in config files

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

## tl;dr

22 messages between Feb 20, 2008 and Feb 25, 2008. Diffs are folded; open one to read it.

replies: 21people: 7as markdown or json

Daniel Barkalow· Feb 20, 2008, 18:43 UTC · lore

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(-)
Show changes to 4 files +164 −3

Documentation/config.txt, Documentation/urls.txt, remote.c, t/t5516-fetch-push.sh

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
Junio C Hamano· Feb 20, 2008, 19:15 UTC · re: Daniel Barkalow · lore

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

Daniel Barkalow <barkalow@iabervon.org> writes:
Show 21 quoted lines
> 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.

Show 13 quoted lines
> 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???
Show 17 quoted lines
> 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???
Daniel Barkalow· Feb 20, 2008, 19:24 UTC · re: Junio C Hamano · lore

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

On Wed, 20 Feb 2008, Junio C Hamano wrote:
Show 30 quoted lines
> 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".

Show 15 quoted lines
> > 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.
Show 19 quoted lines
> > 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*
Junio C Hamano· Feb 20, 2008, 19:42 UTC · re: Daniel Barkalow · lore

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

Daniel Barkalow <barkalow@iabervon.org> writes:
Show 15 quoted lines
> 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".

Show 21 quoted lines
>> > 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.

Jay Soffian· Feb 20, 2008, 19:54 UTC · re: Junio C Hamano · lore

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

On Feb 20, 2008 2:42 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 19 quoted lines
> 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.
Daniel Barkalow· Feb 20, 2008, 20:42 UTC · re: Junio C Hamano · lore

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

On Wed, 20 Feb 2008, Junio C Hamano wrote:
Show 25 quoted lines
> 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".

Show 9 quoted lines
> 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.

Show 23 quoted lines
> >> > 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*
しらいしななこ· Feb 20, 2008, 22:02 UTC · re: Junio C Hamano · lore

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

Quoting Junio C Hamano <gitster@pobox.com>:
Show 19 quoted lines
> 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
Johannes Schindelin· Feb 20, 2008, 22:22 UTC · re: しらいしななこ · lore

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

Hi,
On Thu, 21 Feb 2008, しらいしななこ wrote:
Show 23 quoted lines
> 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

Junio C Hamano· Feb 21, 2008, 00:47 UTC · re: Johannes Schindelin · lore

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

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 11 quoted lines
> 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.

Jay Soffian· Feb 21, 2008, 01:26 UTC · re: Junio C Hamano · lore

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

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.
Linus Torvalds· Feb 21, 2008, 01:47 UTC · re: Jay Soffian · lore

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

On Wed, 20 Feb 2008, Jay Soffian wrote:
Show 13 quoted lines
> 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
Jay Soffian· Feb 21, 2008, 02:19 UTC · re: Linus Torvalds · lore

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

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

Show 24 quoted lines
>  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.
Daniel Barkalow· Feb 21, 2008, 05:04 UTC · re: Linus Torvalds · lore

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

On Wed, 20 Feb 2008, Linus Torvalds wrote:
Show 57 quoted lines
> 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*
Junio C Hamano· Feb 21, 2008, 05:34 UTC · re: Daniel Barkalow · lore

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

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.

Junio C Hamano· Feb 25, 2008, 04:08 UTC · re: Junio C Hamano · lore

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

Junio C Hamano <gitster@pobox.com> writes:
Show 8 quoted lines
> 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(-)
Show changes to 4 files +26 −30

Documentation/config.txt, Documentation/urls.txt, remote.c, t/t5516-fetch-push.sh

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 &&
Daniel Barkalow· Feb 25, 2008, 04:30 UTC · re: Junio C Hamano · lore

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

On Sun, 24 Feb 2008, Junio C Hamano wrote:
Show 18 quoted lines
> 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*
Junio C Hamano· Feb 25, 2008, 06:22 UTC · re: Daniel Barkalow · lore

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

Daniel Barkalow <barkalow@iabervon.org> writes:
Show 15 quoted lines
> 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(-)
Show changes to 2 files +40 −19

Documentation/config.txt, remote.c

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)
Daniel Barkalow· Feb 25, 2008, 06:35 UTC · re: Junio C Hamano · lore

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

On Sun, 24 Feb 2008, Junio C Hamano wrote:
Show 23 quoted lines
> 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*
Jon Loeliger· Feb 21, 2008, 16:31 UTC · re: Linus Torvalds · lore

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

Linus Torvalds wrote:
Show 6 quoted lines
> 
> 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 ]
Show 6 quoted lines
> 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.
Show 20 quoted lines
> 	[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
Jay Soffian· Feb 20, 2008, 19:49 UTC · re: Daniel Barkalow · lore

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

On Feb 20, 2008 2:24 PM, Daniel Barkalow <barkalow@iabervon.org> wrote:
Show 6 quoted lines
> 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.
Junio C Hamano· Feb 20, 2008, 19:58 UTC · re: Jay Soffian · lore

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

"Jay Soffian" <jaysoffian@gmail.com> writes:
Show 13 quoted lines
> 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.
Jay Soffian· Feb 20, 2008, 20:22 UTC · re: Junio C Hamano · lore

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

On Feb 20, 2008 2:58 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 18 quoted lines
>
> "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.
?

← back to recent threads