Re: Git chokes on large file
- From
- David Lang <david@lang.hm>
- Date
- May 28, 2014, 18:23 UTC
- Message-ID
- <alpine.DEB.2.02.1405281121200.32611@nftneq.ynat.uz>
- In-Reply-To
- <201405281815.s4SIF5hF025886@hobgoblin.ariadne.com>
On Wed, 28 May 2014, Dale R. Worley wrote:
Show 18 quoted lines
>> From: Duy Nguyen <pclouds@gmail.com> > >> I don't know how many commands are hit by this. If you have time and >> gdb, please put a break point in die_builtin() function and send >> backtraces for those that fail. You could speed up the process by >> creating a smaller file and set the environment variable >> GIT_ALLOC_LIMIT (in kilobytes) to a number lower than that size. If >> git attempts to allocate a block larger than that limit it'll die. > > I don't use Git enough to exercise it well. And there are dozens of > commands with hundreds of options. > > As someone else has noted, if I run 'git commit -q --no-status', it > doesn't crash. > > It seems that much of Git was coded under the assumption that any file > could always be held entirely in RAM. Who made that mistake? Are > people so out of touch with reality?
Git was designed to track source code, there are warts that show up in the implementation when you use individual files >4GB
such files tend to also not diff well. git-annex and other offshoots hae methods boled on that handle such large files better than core git does.
David Lang