From: Jakub Narebski <jnareb@gmail.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Junio C Hamano <gitster@pobox.com>,
Bruno Cesar Ribas <ribas@c3sl.ufpr.br>,
git@vger.kernel.org
Subject: Re: [PATCH] gitweb: Use config file or file for repository owner's name.
Date: Fri, 1 Feb 2008 01:17:07 +0100 [thread overview]
Message-ID: <200802010117.08295.jnareb@gmail.com> (raw)
In-Reply-To: <alpine.LSU.1.00.0801311110280.23907@racer.site>
On Thu, 31 Jan 2008, Johannes "Dscho" Schindelin wrote:
> 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
next prev parent reply other threads:[~2008-02-01 0:17 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-30 5:28 [PATCH] gitweb: Use config file or file for repository owner's name Bruno Ribas
2008-01-30 5:28 ` [PATCH] gitweb: Update gitweb/README to include the new per-repository configuration Bruno Ribas
2008-01-30 6:16 ` [PATCH] gitweb: Use config file or file for repository owner's name Junio C Hamano
2008-01-31 2:36 ` Bruno Cesar Ribas
2008-01-31 2:48 ` Junio C Hamano
2008-01-31 3:02 ` Bruno Cesar Ribas
2008-01-31 3:06 ` Junio C Hamano
2008-01-31 3:36 ` Jakub Narebski
2008-01-31 11:12 ` Johannes Schindelin
2008-02-01 0:17 ` Jakub Narebski [this message]
2008-02-04 13:35 ` Bruno Cesar Ribas
2008-02-04 14:00 ` Jakub Narebski
2008-02-05 4:41 ` Bruno Cesar Ribas
2008-02-05 10:04 ` Jakub Narebski
2008-02-05 14:28 ` Bruno Cesar Ribas
2008-02-07 4:12 ` Bruno Cesar Ribas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200802010117.08295.jnareb@gmail.com \
--to=jnareb@gmail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=ribas@c3sl.ufpr.br \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.