Git clone fails with out of memory error - "fatal: out of memory, malloc failed (tried to allocate 905574791 bytes) / fatal: index-pack failed"

Question

I'm attempting to clone a large (1.4GB) Git repository to a 32-bit Debian VM with 384MB of RAM. I'm using Git 1.7.2.5, and using the SSH protocol to clone ('git clone [email protected]:/my/repo')

The clone fails with this message:

remote: Counting objects: 18797, done.
remote: warning: subobtimal pack - out of memory
remote: Compressing objects: 100% (10363/10363), done.
fatal: out of memory, malloc failed (tried to allocate 905574791 bytes)
fatal: index-pack failed

I've tried reducing the amount of memory Git uses to repack on the host repository end, and repacking:

git config pack.windowMemory 10m
git config pack.packSizeLimit 20m
git repack -a -d

My questions are as follows:

1. Is this a client-size (clone-side) problem or should it be resolved in the repo that I'm cloning from?

2. In either case, is there anything I can do to make the clone succeed? A lot of the potential solutions online involve some/all of the following things, none of which are acceptable in this instance:

   • changing the contents of the repository substantively (i.e. deleting large files)
   • giving the VM which is doing the clone more RAM
   • giving the VM which is doing the clone a 64-bit virtual CPU
   • transferring out-of-band (e.g. using Rsync or SFTP to transfer the .git directory)

Thanks in advance.

Answer 1

git clone will not look at your pack.packSizeLimit setting, it'll anyway transfer everything in a single pack - unless it changed since the last time I looked.

Using SCP or Rsync might be a way to work around your issue indeed. Removing the "useless" large files, then repacking the repository you try to clone could also help.

Giving more RAM to the VM might also help - I don't think you'll need a 64-bits address space to allocate 900MB... You could also give it enough SWAP space to handle the 900MB package instead of increasing the RAM.