Re: [PATCH] gitweb: Use config file or file for repository owner's name.

[Junio C Hamano <gitster@pobox.com>]

Junio C Hamano <gitster@pobox.com> writes:

> Bruno Cesar Ribas <ribas@c3sl.ufpr.br> writes:
> ...
>> Opening the extra file has same problem as the description file. And, as
>> gitweb allow us to create  "description" and "cloneurl" file there is no 
>> problem having another file to open instead finding out who is the owner of
>> the directory asking to the filesystem.
>
> We heard the same argument when cloneurl was added, and a
> newcomer who does not know that may rightly use the same
> argument.  But I think we should work towards _reducing_ the
> number of such ad-hoc one-line-per-information files, not using
> existing ones as an excuse to add _more_ of them.

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.

If the config reading interface is too slow (somebody has to
bench it on a large set of repositories), maybe we would need to
optimize _THAT_.  If it turns out to be unreasonable (e.g. we
may really want to keep the implementation that spawns "git
config" to do the work, rather than writing and having to
maintain a pure Perl version of config parser inside gitweb,
which is a reasonable position to take in the longer run, but
spawning a process per repository may be too expensive). An
alternative could be to separate out the pieces of information
that are needed even when drawing the top-level project-list
page, and come up with a _new_ single file that is easily
parsable without spawning "git config" for gitweb to read them
(e.g. "description", "owner", perhaps the toplevel project-list
might want to list "cloneurl" as well in the future).