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

Re: Cygwin can't handle huge packfiles?

From
Llinux@horizon.com <linux@horizon.com>
Date
Apr 6, 2006, 20:57 UTC
Message-ID
<20060406205724.12216.qmail@science.horizon.com>
Show 5 quoted lines
> Right now we LRU the pack files and evict older ones when we
> mmap too many, but the unit of eviction is the whole file, so it
> would not help the case like yours at all.  It might be possible
> to mmap only part of a packfile, but it would involve fairly
> major surgery to sha1_file.c.

The simplest solution seems to be to limit pack file size to a reasonable fraction of a 32-bit address space. Say, 0.5 G.

That should be a fairly straightforward hack to git-pack-objects. It already emits two files; just make it emit more.

You can tweak the heurisitics to try to find a good break point: start thinking about splitting the pack when you get to one size, but don't force a break until you hit a harder limit as long as the deltas are working well.

This can all be adjustable with a command line and/or config file option to allow for the eventual demise of 32-bit systems.

Next: Junio C Hamano
Message 1 of 3 in “Re: Cygwin can't handle huge packfiles?”
  1. linux@horizon.comApr 6, 2006
  2. Junio C HamanoApr 6, 2006
  3. linux@horizon.comApr 7, 2006

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.