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

Roadmap to better handle big files?

From
NTNick Triantos <nick@perceptivepixel.com>
Date
Feb 24, 2010, 23:00 UTC
Message-ID
<B85968F5-E7C2-499D-A8BE-0160BA575F10@perceptivepixel.com>
Hi,
Is there any planned functionality to better support large files in git?  (> 100MB / file)
We've been happily using git but we now have some files which we'd very much like to have under the same version control as our source code, and some of those files have been as large as 450MB/file.  We are looking at chunking the file up before commiting it to git, but is there any plan to better support chunking of these files during repacks or other operations?  Right now, it appears either the whole file, or the whole collection of files in a commit (not sure which) can need to be resident in memory up to twice, from reading various places on the web.  Our poor 32-bit server is barfing on this.  We are going to put more RAM and a 64bit OS on the machine, but this still seems like an unnecessary design decision.

thanks very much, -Nick

Next: Nicolas Pitre
Message 1 of 5 in “Roadmap to better handle big files?”
  1. Nick TriantosFeb 24, 2010
  2. Nicolas PitreFeb 24, 2010
  3. Jakub NarebskiFeb 24, 2010
  4. Nick TriantosFeb 25, 2010
  5. Joshua JensenFeb 25, 2010

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.