On Mon, 4 Feb 2008, Bruno Cesar Ribas wrote:
> On Fri, Feb 01, 2008 at 01:17:07AM +0100, Jakub Narebski wrote:
>><snip>
>> Note that some of info is needed for 'projects_list' view, and some only
>> for the 'summary' view.
>> Currently for 'projects_list' view we have, when $projects_list is
>> a directory (this includes situation when it is undef, and fallbacks
>> to $projectroot):
>> 1. Call git-for-each-ref to get last modification time
>> 2. Read $git_dir/description file for description (which is generated
>> by default template, so is usualy present, if in useless form),
>> fallback to git-config / reading $git_dir/config, gitweb.description
>> 3. Check owner of $git_dir (stat + getpwuid)
>>
>> With the addition of $git_dir/owner and gitweb.owner we would have
>> 3'. Read $git_dir/owner file, usually not present,
>> fallback to gitweb.owner (which means reading and parsing
>> repo config!),
>> fallback to $git_dir owner (stat + getpwuid)
>> so after consideration I think that adding gitweb.owner is a bit of
>> a stupid idea from performance point of view, at least till we have
>> 'projects_list' caching. Only $git_dir/owner would be better.
>
> Unless we parse config only once for each project. We can create a small
> cache with all gitweb conf. Then each time we ask
> git_get_project_config('bla') we check if we alread had parsed it, if parsed
> get in a small hash table.
If you have read gitweb.perl current code more carefully, or browsed
"git log -- gitweb" output, you would notice that since b201927a
gitweb: Read repo config using 'git config -z -l'
gitweb does just that. Reads whole repo config using "git config -z -l"
(this additionally includes support for user and system git
configuration files; also git config file format has some hairy corners)
into hash lazily, then uses this hash.
But this is once per repo, which for 'projects_list' might be too much,
especialy for the operating systems where fork is slow. I'd rather go
in opposite direction and add support for providing description in
'projects_list' file.
> We could even check if we are generating project list then we can store only
> description and owner. (this sounds ugly)
This doesn't buy us much, because description and owner migh be in the
last lines of repo config, so we have to read whole config file in full.
Note that if I understand this correctly variable initialization,
including %config and $config_file are generated anew for each request.
Besides, as it is now, viewing some project view would flush out
projects_list %config, etc.
>> Another solution would be using $projectroot/.gitconfig, with simplified
>> syntax easy parseable by Perl, with gitweb.<repo path>.<config>, where
>> <config> is limited to 'description', 'owner' and 'url', and
>> gitweb.description for fallback description, gitweb.owner for fallback
>> owner and owner for set of repositories, gitweb.baseurl for base URLs
>> (gitweb.<repo>.url = gitweb.baseurl/<repo>).
>
> This sounds good. Having this small, simple file would make things better.
> But we will have another file inside repository, having all in config would
> be cleaner [i guess]. If we parse config file only once per project might be
> good.
I think that it would be better to separate gitweb configuration
(in gitweb_config.perl) fro [cached] repositories configuration
(in gitconfig or .gitconfig).
--
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
