Re: Roadmap to better handle big files?
- From
- Nick Triantos <nick@perceptivepixel.com>
- Date
- Feb 25, 2010, 00:02 UTC
- Message-ID
- <2009C5FE-F0B7-4D64-BF5C-04087E17EDF1@perceptivepixel.com>
- In-Reply-To
- <m3fx4qmbwr.fsf@localhost.localdomain>
Thanks. I had looked at that project, but the logo being a piece of poop sort of scared me away from it (and it looked to be very early on in their design work so far)...
thanks! -Nick
On Feb 24, 2010, at 3:51 PM, Jakub Narebski wrote:
Show 27 quoted lines
> Nick Triantos <nick@perceptivepixel.com> writes: > >> 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