Re: What's cooking in git.git (Jan 2010, #08; Sun, 24)

From: Jakub Narebski <jnareb@gmail.com>
Date: Jan 25, 2010, 22:43 UTC
Message-ID: <m3eildbydx.fsf@localhost.localdomain>
In-Reply-To: <7vfx5u6bn9.fsf@alter.siamese.dyndns.org>

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

> * jh/gitweb-cached (2010-01-13) 9 commits

>  - gitweb: File based caching layer (from git.kernel.org)
>  - gitweb: Convert output to using indirect file handle

Show 11 quoted lines

>  - gitweb: cleanup error message produced by undefined $site_header
>  - gitweb: add a get function to compliment print_sort_th
>  - gitweb: add a get function to compliment print_local_time
>  - gitweb: Makefile improvements
>  - gitweb: Add option to force version match
>  - gitweb: change die_error to take "extra" argument for extended die information
>  - gitweb: Load checking
> 
> I know there is a series to split the later ones into smaller chunks that
> are being discussed on the list, but they don't appear here.  I'd prefer
> to pick the series up after all the dust from the discussion settles.

Well, this series actually consist of two parts: miscellaneous gitweb
improvements and actual gitweb output caching.  The first part is more
or less ready; in particular the following patches are I think ready
for inclusion:
 - gitweb: Makefile improvements
 - gitweb: change die_error to take "extra" argument for extended die information
 - gitweb: Load checking
(Although die_error improvements is used by 'force version match',
which is not ready yet).

The following patches needs minimal fixups or extensions.  In
 - gitweb: add a get function to compliment print_sort_th
 - gitweb: add a get function to compliment print_local_time
IMVHO the new (unused) get_* functions should really be named format_*
to follow gitweb convention for naming subroutines.  And of course
that would probably require accompanying change to the commit message.

The patch
 - gitweb: cleanup error message produced by undefined $site_header
solves its problem... but not fully.  There are other variables
holding file names that could, in theory, be undefined.  Also the
commit message should perhaps mention that is defensive coding against
errors in gitweb config file, as in normal situation those variables
would be set to empty string, but not undefined.

I am not sure about the
 - gitweb: Add option to force version match
patch.  It is not that useful if the feature is turned off by default;
on the other hand if the feature is turned on by default the error
message needs to be changed... and be a bit more complicated in the
case when there are no config files (see my reply in thread).

You are right that actual caching support is in flux. The discussion continues: it is very good that we have the voice from Pasky, too.

-- 
Jakub Narebski
Poland
ShadeHawk on #git