Jakub Narebski <jnareb@xxxxxxxxx> 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 ;-) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html