Re: Gitweb: Show git clone url on projects list

[Jakub Narebski <jnareb@gmail.com>]

On Mon, 11 Oct 2010, J.H. wrote:
> Sorry for the late response, was traveling on the 7th.  Comments inline.
> 
> > There were multiple attempts to add such link to core gitweb (i.e. the
> > one present in git 1.7.3), but were not merged in due to runing
> > aground the following problems:
> > 
> > 1. There might be more than one link for one git repository.  One can
> >    provide git://, http:// and ssh:// URLs.  Which one to chose?
> > 
> >    This issue might be solved by either using first one on the list,
> >    or filtering and showing link(s) to anonymous unauthenticated ones,
> >    i.e. _git_ link (if git:// URL exists) and perhaps _http_ link (if
> >    http:// URL exists).
> 
> If you are running a uniform enough site, http://git.kernel.org,
> http://git.fedorahosted.org/git/, etc it's easy enough to deal with.
> This only becomes an issue if/when you allow more generic trees to
> exist, and aren't expecting a uniform git link.

The issue is that solution in core gitweb (as opposed to local version)
should be generic enough.  Is supporting single link per repository
generic enough?

> > 2. More important issue is that besides @git_base_url_list the URL or
> >    URLs for a repository can come from various other places: from
> >    'cloneurl' text file and from `gitweb.url' configuration variable.
> >    It it was taken into account (even to check that such configuration
> >    does not exist) it would badly affect performance of generating
> >    projects list page.
> > 
> >    The git.kernel.org gitweb doesn't have this problem because it uses
> >    @git_base_url_list (I think unconditionally); also it supports
> >    output caching, so eventual performance hit is migitated.
> 
> We actually don't, at least currently, use @git_base_url_list.  Right
> now there's a configuration variable to set a uniform server / base url,
> and then use project path to append to that.  git:// in this case is
> hard coded, though with http being smart now there is no reason why that
> should be that way (no one has asked for the change &/or submitted a
> patch to me to alter that behavior).

Well, @git_base_url_list by default is empty or is single-element list
filled using GITWEB_BASE_URL build time configuration variable.  The
URL or URLs for a repository are composed of elements of @git_base_url_list
concatenated with project name; in most common non-empty case it would be

  "$git_base_url_list[0]/$project"

while, from what I understand, the solution used by http://git.kernel.org
is

  "git://$gitlinkurl/$project"

Not much difference.
 
> The caching helps, though since I'm not actually using @git_base_url the
> caching isn't of significant impact, since I only need to know the path
> vs. poking in the repo directly.  (that said caching still buys me a lot
> of performance overall).
> 
> Assuming you are using my caching version of gitweb setting $gitlinkurl
> in your config file to be the base (before the path) of your link, it
> should work.  Should get that even if caching is disabled, though YMMV I
> don't do a lot of testing with the cache turned off, and I haven't
> written a test case for that yet.

Caching is not necessary when using only @git_base_url_list, but is
necessary when project URLs can come from $projectroot/$project/cloneurl
file, or from `gitweb.url` repository config.  And even if they are not
set, if they can be used, we have to check them.

The solution might be to specify somehow that only @git_base_url_list
(or even only $git_base_url_list[0]) is to be taken into account when
generating _git_ links on project list page.

-- 
Jakub Narebski
Poland