4

I have migrated an old cvs repository (ca 13GB big) to git (ca. 2,7GB big). But I cannot clone the repo with my 32-Bit workstation. I get an out of memory error (malloc failed to allocate ca. 6 MB). Is there a possibility to fix this?

remote: counting objects: 1227276, done.
remote: Compressing objects: 100% (217540/217540), done.
Receiving objects: 100% (1227276/1227276), 2,66GiB | 791.00KiB/s, done.
remote: Total 1227276 (delta 787852), reused 1227276 (delta 787852)
Resolving deltas: 100% (787852(787852), done.
fatal: Out of memory, malloc failed (tried to allocate 6838754 bytes)
fatal: remote did not send all necessary objects

Server: Rhel63 64bit; Wokstation: Win XP 32bit, 2GB RAM; Git: 1.8.3.4 on both.

Update1: Now I have repacked the 2,8GB big pack file on the server into 500MB big pack files. But on client side it has no effect to the clone. It creates only one 2,8GB big pack file. How can I tell the git clone process to user smaller pack-files or to create the pack-files as they are placed on server? - Aninteresting aspect for me: the size of te received objects decreases to 1,5GB.

Update2: Now after some research and analyzing time I think the main problem is that the git clone process cannot handle the one big pack file on my 32-Bit workstation. But how can I configure the cloning process in order to get several pack files with lesser size? On server side it works with the repack command very well, but it does not effect the client side.

Update 3: Now I have an 1.1GB big bare git repo (by using git gc --aggressive --prune=now). But the out-of-memory error was still there. So I have tried to split the repo. Thereby I have used git rm with git commit -a. So the size of both two new bare repos is equal to the old central one. But now the cloning from the workstation does work. The memory consumption is now constant < 300MB. Before it increases unstoppable.

Now my questions is: Why does the cloning process now finish without problems?

user2451418
  • 1,387
  • 4
  • 15
  • 27
  • Have you checked some of the other similar questions about tuning Git?: http://stackoverflow.com/questions/10292903/git-on-windows-out-of-memory-malloc-failed/12808378#12808378 http://stackoverflow.com/questions/7607970/git-clone-fails-with-out-of-memory-error-fatal-out-of-memory-malloc-failed https://github.com/gitextensions/gitextensions/issues/1632 – Display Name is missing Aug 14 '13 at 22:29
  • yes, but those couldn't help me. I have added the error message, which I have get by trying to git clone. – user2451418 Aug 15 '13 at 10:50
  • Now I have tried several git config settings like ´pack.packSizeLimit = 256m pack.windowMemory = 256m pack.deltaCacheSize =256m core.packedGitLimit = 256m core.packedGitWindowSize = 256m transfer.unpackLimit = 100000´ as supposed in similiar posts on the internet. But the error message ist still there. Only the size has been shrinked from 6mb to 4mb which git cannot allocate. I have made the configuration on server, on client side and also during the clone process. But nothing works. – user2451418 Aug 16 '13 at 16:30
  • Did you try partial cloning? https://docs.gitlab.com/ee/topics/git/partial_clone.html – Sergei Krivonos Jan 04 '20 at 19:54

1 Answers1

1

If anything, you can archive the .git directory, then scp it locally, then unarchive it. And so there is your cloned repository.

Once it is working with the git command, then link to the remote repository using 'git remote add'. You should be able to pull and push at that point. I'm not sure this is entirely satisfactory, however, if you have to repeat this process.

user2687644
  • 101
  • 3
  • thank you. Yes this is definitely an opportunity. But the problem is that I need to make the repository available for 30 Persons. So this workaround is maybe too inconvenient. There must be a way to handle a 3 GB repository. In worst case I think I have to split the repo into parts. But the problem is that then the change maybe is too large concerning the project team. Because the most people are only familiar with cvs. – user2451418 Aug 16 '13 at 16:25