git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [RFD] My thoughts about implementing gitweb output caching

From
Nicolas Pitre <nico@fluxnic.net>
Date
Jan 8, 2011, 02:46 UTC
Message-ID
<alpine.LFD.2.00.1101072142550.22191@xanadu.home>
In-Reply-To
<20110108002643.GD15495@burratino>
On Fri, 7 Jan 2011, Jonathan Nieder wrote:
Show 12 quoted lines
> > With output caching gitweb can also support 'Range' requests, which
> > means that it would support resumable download.  This would mean hat we
> > would be able to resume downloading of snapshot (or in the future
> > bundle)... if we cannot do this now.  This would require some more code
> > to be added.
> 
> Exciting stuff.
> 
> Teaching gitweb to generate bundles sounds like a recipe for high server
> loads, though.  I suspect manual (or by cronjob) generation would work
> better, with a possible exception of very frequently cloned and
> infrequently pushed-to repos like linus's linux-2.6.

Even for Linus' linux repo, it is not a good idea to auto create bundle, except maybe once every major release which is every 3 months or so. I really don't think this is a good idea to put this in the realm of gitweb caching.

Nicolas
Previous: Jonathan NiederNext: Jakub Narebski
Message 3 of 5 in “[RFD] My thoughts about implementing gitweb output caching”
  1. Jakub NarebskiJan 7, 2011
  2. Jonathan NiederJan 8, 2011
  3. Nicolas PitreJan 8, 2011
  4. Jakub NarebskiJan 8, 2011
  5. Jakub NarebskiJan 8, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.