Re: [PATCH] gitweb: Use config file or file for repository owner's name.
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- Feb 1, 2008, 00:17 UTC
- Message-ID
- <200802010117.08295.jnareb@gmail.com>
- In-Reply-To
- <alpine.LSU.1.00.0801311110280.23907@racer.site>
On Thu, 31 Jan 2008, Johannes "Dscho" Schindelin wrote:
Show 28 quoted lines
> On Wed, 30 Jan 2008, Jakub Narebski wrote: >> Junio C Hamano <gitster@pobox.com> writes: >>> Junio C Hamano <gitster@pobox.com> writes: >>> >>> Rephrasing to be constructive (but remember, this is all post 1.5.4). >>> >>> * we would need for historical reasons to keep supporting >>> description and cloneurl for some time. There may be some >>> others, but the goal should be to deprecate and remove these >>> ad-hoc one-file-per-piece-of-information files. >>> >>> * we also need for historical reasons to keep supporting some >>> other stuff found in $git_dir/config of the project. >>> >>> If the config reading interface in gitweb is reasonably fast and >>> cheap, we can move the existing description/cloneurl to gitweb config >>> when deprecating them. New ones such as "owner" would naturally fit >>> there. >> >> Currently gitweb parses repo config file _once_, using one call to >> git-config -z -l. >> >> We could simply add description to the projects_list file, but it will >> be a bit backwards incompatibile change. > > Not if you say "the config overrides the description/cloneurl file", i.e. > when there is a description or a cloneurl from the config, don't even > bother to stat the single-line files.
Errr... what I wanted to say there is instead of current format of
'projects_list' file which is:
<URI-encoded project path> SPC <URI-encoded owner> LF
add also project description to that file, so the format would be
<URI-encoded project path> SPC <URI-encoded owner> SPC
<one-line project description> LF
(project description doesn't need to be URI encoded). This means
avoiding reading $git_dir/description (and in rare cases also avoiding
gitweb.description in $git_dir/config).This is of course a bit backwards incompatibile.
> That would help transition, and still be backwards compatible. (BTW this > resembles what we did for the .git/remotes/* -> .git/config transition.)
Note that some of info is needed for 'projects_list' view, and some only for the 'summary' view. For the 'projects_view' page we would want to avoid, I think, calling "git config -z -l" per repository (or opening $git_dir/config file and [limited] parsing it inside gitweb in Perl, like git-cvsserver does). For 'summary' view we want usually to read repo config file for features nevertheless, and is only once per web-page, so we don't avoid it then.
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.
BTW. what about filesystems where file / directory does not have
an owner?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 would limit repo paths to not have embedded newlines in them, but this is not I think serious limitation :-)
-- Jakub Narebski Poland