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

Re: Roadmap to better handle big files?

From
Jakub Narebski <jnareb@gmail.com>
Date
Feb 24, 2010, 23:51 UTC
Message-ID
<m3fx4qmbwr.fsf@localhost.localdomain>
In-Reply-To
<B85968F5-E7C2-499D-A8BE-0160BA575F10@perceptivepixel.com>
Nick Triantos <nick@perceptivepixel.com> writes:
Show 14 quoted lines
> 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.
Git has a roadmap???

More seriously, take a look at git-bigfiles project (fork): http://caca.zoy.org/wiki/git-bigfiles

HTH
-- 
Jakub Narebski
Poland
ShadeHawk on #git
Previous: Nicolas PitreNext: Nick Triantos
Message 3 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.