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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html