Take the 2-minute tour ×

Final update and fix: The solution here turned out to be a combination of two things: using Windows Git rather than Cygwin Git as Graham Borland suggested, and the Git config settings pack.threads = 1 and gc.aggressiveWindow = 150.

I have a large local Git repository, a git svn clone of an SVN repository with about 40,000 commits. I'm trying to run git gc over this repository, and getting nowhere:

$ git gc --auto
Auto packing the repository for optimum performance. You may also
Counting objects: 25966, done.
Compressing objects: 100% (25249/25249), done.
fatal: Out of memory, malloc failed (tried to allocate 426523986 bytes)
error: failed to run repack

I'm running Git inside Cygwin on a 64-bit dual-core Win7 machine with 4GB RAM. The .git directory is currently a little over 6.1GB.

I've tried running git gc --aggressive, to see if the more complete system is able to fix it, but no luck: I get a similar message to the above, with the same size attempted malloc, but a considerably higher object count (508,485 counted, 493,506 compressed).

I've also tried—as suggested by Google—assorted twiddles to the [pack] part of my .gitconfig file; the most complete being from another StackOverflow question. My .gitconfig now has the following relevant lines, but setting these appears to have made no difference:

        windowMemory = 16m
        threads = 1
        window = 1
        depth = 1
        deltaCacheSize = 1

Any suggestions on how I can get git to gc my repository?

Edit: Mark Longair suggested some more .gitconfig file changes. Which I made, new lines below. But the changes made no difference whatsoever.

        packedGitWindowSize = 1m
        packedGitLimit = 256m
        packSizeLimit = 128m

Edit 2: Michael Krelin suggested increasing the swap/page file size (WinXP instructions here, and it's similar for Win7). I tried that, but it made no difference, and indeed I only increased the maximum size available, and it looks as if Windows never tried to increase the size of the page file it was using.

I'm now looking at whether this was caused by a memory limit within or imposed upon Cygwin. To check "imposed upon", I'm trying running Cygwin with administrator privileges. To check "within" (which looks more likely), I'm having a play with Cygwin's maximum memory settings.

Edit 3: Much though I may prefer using Cygwin, it turns out the Windows Git client deals with the memory issue just fine. Seems I'll be falling back to that every so often when my repository needs a tidy.

share|improve this question
add comment

5 Answers

up vote 5 down vote accepted

You might have more luck running a native Windows client such as msysGit, rather than trying to do it inside Cygwin.

share|improve this answer
My experience of Windows Git clients has generally been that they handle memory management even worse—I've been able to get Cygwin Git to handle a ~15,000 commit SVN repository that the Windows Git client I tried barfed on. Still, worth a shot, I guess! –  me_and Nov 21 '11 at 17:32
Whee! Much as I may not like using the Windows Git client normally, that worked just fine. Thank you! –  me_and Nov 22 '11 at 11:50
add comment

Some other config options that you might want to try restricting to lower than default values include:

  • pack.packSizeLimit
  • core.packedGitWindowSize
  • core.packedGitLimit

... all of which are documented in the git config documentation. It's particularly worth checking in each case what units are understood, which I've made mistakes with in the past.

share|improve this answer
There is no core.deltaCacheSize. I suspect you're referring to pack.deltaCacheSize, which I've already been adjusting. I'll try the rest of those out now, though, thanks! –  me_and Nov 21 '11 at 16:19
@me_and: oops - I've removed that one from my answer –  Mark Longair Nov 21 '11 at 17:09
No luck. I'll update the question with the new config I used, but the short version is that none of your suggested changes seemed to make any difference to the amount of memory git gc tried to allocate. –  me_and Nov 21 '11 at 17:11
add comment

I had the same problem, tried the solutions mentioned so far without success. But my problems with git gc began after I added big image files to repo, so I created .gitattributes file and turned off delta compression for those big files:

*.tga -delta
*.psd -delta

It worked.

share|improve this answer
ZOMG it worked! I've been having trouble with large files in my git repositories on a shared host which kills processes that take up too much memory. THIS SOLVED A PROBLEM I'VE HAD FOR YEARS :DDDD –  scone Dec 16 '13 at 7:45
After a lot of trial and error, sometimes getting it working and then after a few commit have the repo break again, this brought the solution (so far). I think this answer should be higher up. –  Michel Müller Feb 10 at 19:19
add comment

Maybe temporarily adding a swap file bigger than life and going for a few cups of coffee elsewhere will help?

share|improve this answer
If I don't get anywhere today, I'll reboot my computer with a massive page file this evening and leave it going overnight… –  me_and Nov 21 '11 at 16:27
Oh, I didn't realize you were on windows — I assumed adding swap file is a matter of a few commands in shell. Well, I hope it's still possible on windows, but you know better how to do that ;-) –  Michael Krelin - hacker Nov 21 '11 at 17:17
No luck. In fact, I increased the available page file space, but Windows didn't decide to use it, which implies to me that there may be some Cygwin memory limit issue. I'm investigating that now… –  me_and Nov 22 '11 at 10:39
Maybe cygwin implements ulimit? (I have no idea) –  Michael Krelin - hacker Nov 22 '11 at 10:50
There does indeed seem to be something similar: there's a Windows registry setting for Cygwin's maximum memory usage. More experimenting is occurring as I type! –  me_and Nov 22 '11 at 11:01
add comment

The only thing that help to avoid this error on shared Linux hosting was to add

    packSizeLimit = 64m
    threads = 1



Most important was "threads = 1"

share|improve this answer
add comment

Your Answer


