On Tue, 29 Jan 2008, Bruno Cesar Ribas wrote: > On Tue, Jan 29, 2008 at 03:26:31AM -0800, Jakub Narebski wrote: >> Bruno Ribas <ribas@xxxxxxxxxxxx> writes: >> >>> This file ($projectroot/$project/owner) is good to have when we don't want to >>> maintain a project list AND when we share same SSH account for all projects, >>> using ssh_acl for example. >>> >>> Signed-off-by: Bruno Ribas <ribas@xxxxxxxxxxxx> >> >> This explanation is a bit too complicated; it explains farther >> reasons, instead of immediate ones: you don't want to maintain project >> list file, and all repository directories have to have the same owner >> (for example when the same SSH account is shared for all projects, >> using ssh_acl to control access instead). > > I'm sorry about this complicated explanation. It is not [that] bad description, but it could be better. Also, 80 columns word wrap is good, but 72-76 would be even better :-) >> Besides with new faster config reader we probably would want to allow >> to use config file to set owner, instead of adding yet another file to >> the repo area; see commit 0e121a2cd42d28bc4034feedf8a13c5a91f85bd3 >> "gitweb: Use config file for repository description and URLs" >> This would have the advantage that you could use system config >> (/etc/gitconfig) to set fallback owner instead of relying on >> filesystem. I'm not sure what should be the preference, though: >> gitweb.owner, then $GIT_DIR/owner, or vice versa? I guess that >> reading $GIT_DIR/owner should take preference, as it is needed also >> for projects list page, where ordinary we didn't read individual >> repositories configuration. > > Reading $GIT_DIR/owner would be the preference, Maybe it can generate project > list page faster when machine have high IO waits (WA). Yes, I also think so. Two file reads (description + owner) should be still faster than one running git-config, and parsing its output. But I think if IO matters it is better to generate projects list; you can even use gitweb for that, or you can simply add a line with URL escaped project name (project path) relative to $projectroot, separated by space from the URL escaped (URI-encoded) project owner. See also "Gitweb repositories" section in gitweb/INSTALL. Adding projects is rare event. > Having gitweb.owner is good too, but as you said I don't need to read > individual repositories configuration. > > Having another file at the repo area is not a problem (my say). Sometimes > having files appears to be more organized than having everything in one file > (my say again). By the way, I have forgot to ask you to add description of new 'owner' file to "Per-repository gitweb configuration" section in gitweb/README > I even made another patch about cloneURL, instead of looking for inside files > and stuff, i made gitweb.conf a variable that says: > - If i have a prefix path for HTTP,SSH,GIT[protocol] > Then if this variable is set gitweb only mounts... like > HTTPPREFIX="http://git.c3sl.ufpr.br/pub/scm"; > and gitweb sets it to $HTTPREFIX/$project > > I made this because I don't want to set each project it's clone URL, so this > makes thing easier! What do you think? I hope that this hack predates latest improvements to gitweb/README, as you have just reimplemented GITWEB_BASE_URL build configuration variable (only single base URL), and @git_base_url_list, which you can set in gitweb config file (by default gitweb_config.perl). If you have read current code carefully, you should notice that currently gitweb generates URLs for repository in the following way: 1. Per repository configuration: a. $projectroot/$project/cloneurl (one line perl URL) b. multivalued gitweb.url configuration variable in project config 2. Global gitweb configuration a. $prefix/$project for each $prefix element in @git_base_url_list, which is set in gitweb_config.perl 3. Build time defaults a. Single value in @git_base_url_list set using GITWEB_BASE_URL build configuration variable 4. Otherwise it is not set (it is empty). -- 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
