git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, "J.H." <warthog9@eaglescrag.net>,
	"John 'Warthog9' Hawley" <warthog9@kernel.org>,
	Petr Baudis <pasky@suse.cz>
Subject: Re: What's cooking in git.git (Jan 2010, #08; Sun, 24)
Date: Mon, 25 Jan 2010 14:43:01 -0800 (PST)	[thread overview]
Message-ID: <m3eildbydx.fsf@localhost.localdomain> (raw)
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

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

  parent reply	other threads:[~2010-01-25 22:43 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-25  4:39 What's cooking in git.git (Jan 2010, #08; Sun, 24) Junio C Hamano
2010-01-25 18:29 ` Issues that need to be resolved before 1.7.0-rc1 Junio C Hamano
2010-01-25 21:17   ` Johannes Sixt
2010-01-25 22:43 ` Jakub Narebski [this message]
2010-01-25 23:12   ` What's cooking in git.git (Jan 2010, #08; Sun, 24) Petr Baudis
2010-01-25 23:47     ` Junio C Hamano
2010-01-26  0:07     ` Jakub Narebski
2010-01-26  0:21       ` J.H.
2010-01-26  0:59         ` Jakub Narebski

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=m3eildbydx.fsf@localhost.localdomain \
    --to=jnareb@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=pasky@suse.cz \
    --cc=warthog9@eaglescrag.net \
    --cc=warthog9@kernel.org \
    /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).