On Wed, 16 Dec 2009, Junio C Hamano wrote: > Not that I am anxious to queue new topics to 'next' right now (we are > frozen for 1.6.6), but I think having what is proven to work well at a > real site like k.org is much better than waiting for an unproven > reimplementation using somebody else's framework only for your theoretical > cleanliness. John has better things to do than doing such a rewrite > himself, and even if you helped the process by producing a competing > caching scheme based on existing web caching engines, the aggregated > result (not just the web caching engine you base your work on) needs to > get a similar field exposure to prove itself that it can scale to the load > k.org sees, which would be quite a lot of work, no? I'm not against (well, not much against) custom caching that kernel.org uses, but I am against large change to gitweb code currently accompanying caching, namely gather then output solution, which would negatively affect performance when caching is turned off. Also I'd like to have caching code (the one that didn't made it to git mailing list for some reason, probably vger anti-SPAM filter) cleaned up for submission: remove commented-out code, reduce code duplication, separate dealing with orthogonal issues (cache itself, adaptivity of cache, background generation and 'in progress' info, generating key for cache (and improve key generation to include path_info / use %input_params)), follow the same style that gitweb itself uses. As for the "[PATCH 6/6] GITWEB - Separate defaults from main file" patch, it would require modifying gitweb tests to use generated gitweb/gitweb.cgi rather than source gitweb/gitweb.perl. As for having caching code tested by git.kernel.org: IIRC there was issue with it not having cache expiration thus gathering GB of cached data. -- Jakub Narebski Poland -- 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