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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 31, 2008, 03:06 UTC
Message-ID: <7vabmmg0cb.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <7vsl0eg16c.fsf@gitster.siamese.dyndns.org>

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

Show 12 quoted lines

> 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).