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

Jakub Narebski [off-list ref] writes:

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

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

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

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

Jakub Narebski [off-list ref] writes:

quoted

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

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

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

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

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

So, something like:

diff --git a/Documentation/urls.txt b/Documentation/urls.txt
index 81ac17f..f47b9e0 100644
--- a/Documentation/urls.txt
+++ b/Documentation/urls.txt

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

	-Daniel
*This .sig left intentionally blank*

Daniel Barkalow wrote:

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

-- 
Jakub Narebski
Poland