git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).