git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jakub Narebski <jnareb@gmail.com>
Cc: git@vger.kernel.org, "John 'Warthog9' Hawley" <warthog9@kernel.org>
Subject: Re: What's cooking in git.git (Nov 2010, #02; Wed, 17)
Date: Thu, 18 Nov 2010 09:54:27 -0800	[thread overview]
Message-ID: <7v1v6icyb0.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <m3mxp668cy.fsf@localhost.localdomain> (Jakub Narebski's message of "Thu\, 18 Nov 2010 06\:00\:23 -0800 \(PST\)")

Jakub Narebski <jnareb@gmail.com> writes:

> Sidenote: recently sent
>
>   gitweb: selectable configurations that change with each request
>
> practically reverts
>
>   gitweb: Move call to evaluate_git_version after evaluate_gitweb_config
>
> Just FYI.

Hmph, will have to look at it again.

>> * jn/gitweb-time-hires-comes-with-5.8 (2010-11-09) 1 commit
>>  - gitweb: Time::HiRes is in core for Perl 5.8
>> 
>> Looked reasonable.  Will merge to next.
>
> Thanks. With or without improvement to commit message?

I think what I pushed out has already been reworded.  Please check.

>> * jh/gitweb-caching (2010-11-01) 4 commits
>>  . gitweb: Minimal testing of gitweb caching
>>  . gitweb: File based caching layer (from git.kernel.org)
>>  . gitweb: add output buffering and associated functions
>>  . gitweb: Prepare for splitting gitweb
>> 
>> Temporarily ejected while I shuffled jn/gitweb-testing; will queue the
>> latest back in pu or perhaps in next.
>
> The advantage of 'gitweb: File based caching layer (from git.kernel.org)'
> is that it is tested in real-life on heavy load (assuming that 
> git.kernel.org uses the same version as is/would be in pu/next).
>
> The disadvantage is that it is seriously messy code.  Something that I
> wanted to improve in my rewrite.  This is only minimal fixup.

Which is exactly what we want at this point (I want to release 1.7.4 by
the end-of-year holidays, which means a feature-freeze will have to start
soon).  My understanding is that the serious messiness does not come from
the caching layer.

> I am thinking about splitting main 'gitweb: File based caching layer
> (from git.kernel.org)' patch in two, separating moving test for
> $caching_enabled out of cache_fetch to separate commit (largest change
> to original J.H. submission), but leaving hardening "do 'cache.pl';"
> and replacing 0/1 valued $cache_enable with boolean valued 
> $caching_enabled.
>
> Because currently new tests in t9501 and t9502 (examining status and
> output of gitweb with caching enabled) do not pass, I am thinking
> about adding new configuration know turning off "Generating..." page.
>
> BTW. should I forge J.H. signoffs, and add mine?

Just ping him beforehand ;-)

  reply	other threads:[~2010-11-18 17:54 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-18  0:56 What's cooking in git.git (Nov 2010, #02; Wed, 17) Junio C Hamano
2010-11-18 14:00 ` Jakub Narebski
2010-11-18 17:54   ` Junio C Hamano [this message]
2010-11-18 21:33     ` J.H.
2010-11-20  0:42     ` Jakub Narebski
2010-11-24  1:45       ` J.H.
2010-11-24 17:13         ` Junio C Hamano
2010-11-24 21:30           ` Jakub Narebski
2010-11-24 21:26         ` 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=7v1v6icyb0.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=jnareb@gmail.com \
    --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).