Yes. I've added following entry to my  .gitconfig:

[pack]
    packSizeLimit = 20m

What is strange is that if i run git config --list i get following ouput:

core.symlinks=false
core.autocrlf=true
color.diff=auto
color.status=auto
color.branch=auto
color.interactive=true
pack.packsizelimit=2g
help.format=html
http.sslcainfo=/bin/curl-ca-bundle.crt
sendemail.smtpserver=/bin/msmtp.exe
diff.astextplain.textconv=astextplain
rebase.autosquash=true
pack.packsizelimit=20m
user.name=...

The configuration entry pack.packsizelimit appears two time in the list. 
I'm not sure now that my configuration applies...

Igor

Am Freitag, 1. März 2013 14:25:25 UTC+1 schrieb John McKown:
>
> Have you tried any of the "git config" options? 
> http://linux.die.net/man/1/git-config
>
> You might try setting one or more of the following with a 
>
> git config --global
>
> command. No guarantees that any of them will help. Just a wild guess on my 
> part.
>
> <quote>
> core.packedGitWindowSize
>
> Number of bytes of a pack file to map into memory in a single mapping 
> operation. Larger window sizes may allow your system to process a smaller 
> number of large pack files more quickly. Smaller window sizes will 
> negatively affect performance due to increased calls to the operating 
> system's memory manager, but may improve performance when accessing a large 
> number of large pack files.
>
> Default is 1 MiB if NO_MMAP was set at compile time, otherwise 32 MiB on 
> 32 bit platforms and 1 GiB on 64 bit platforms. This should be reasonable 
> for all users/operating systems. You probably do not need to adjust this 
> value.
>
> Common unit suffixes of k, m, or g are supported.
>
> ===
>
> core.packedGitLimit
>
> Maximum number of bytes to map simultaneously into memory from pack files. 
> If Git needs to access more than this many bytes at once to complete an 
> operation it will unmap existing regions to reclaim virtual address space 
> within the process.
>
> Default is 256 MiB on 32 bit platforms and 8 GiB on 64 bit platforms. This 
> should be reasonable for all users/operating systems, except on the largest 
> projects. You probably do not need to adjust this value.
>
> Common unit suffixes of k, m, or g are supported.
>
> ===
>
> core.deltaBaseCacheLimit
>
> Maximum number of bytes to reserve for caching base objects that multiple 
> deltafied objects reference. By storing the entire decompressed base 
> objects in a cache Git is able to avoid unpacking and decompressing 
> frequently used base objects multiple times.
>
> Default is 16 MiB on all platforms. This should be reasonable for all 
> users/operating systems, except on the largest projects. You probably do 
> not need to adjust this value.
>
> Common unit suffixes of k, m, or g are supported.
>
> ===
>
> pack.windowMemory
>
> The window memory size limit used by git-pack-objects(1) when no limit is 
> given on the command line. The value can be suffixed with "k", "m", or "g". 
> Defaults to 0, meaning no limit.
>
> ===
>
> pack.deltaCacheSize
>
> The maximum memory in bytes used for caching deltas in git-pack-objects(1) 
> before writing them out to a pack. This cache is used to speed up the 
> writing object phase by not having to recompute the final delta result once 
> the best match for all objects is found. Repacking large repositories on 
> machines which are tight with memory might be badly impacted by this 
> though, especially if this cache pushes the system into swapping. A value 
> of 0 means no limit. The smallest size of 1 byte may be used to virtually 
> disable this cache. Defaults to 256 MiB.
>
> ===
>
>
>
>
>
>
> On Fri, Mar 1, 2013 at 6:17 AM, Igor Kazarnovskiy <
> igor.kaz...@googlemail.com <javascript:>> wrote:
>
>> Morning :)
>>
>> I have a problem cloning a large GIT repository on a windows XP (32-bit) 
>> machine. The output looks as follows:
>>
>> $ git clone ssh://user@server/.../git/repo/myrepo mylocalrepo
>> Cloning into 'mylocalrepo'...
>> remote: Counting objects: 384454, done.
>> remote: Compressing objects: 100% (64510/64510), done.
>> Receiving objects: 100% (384454/384454), 215.03 MiB | 5.65 MiB/s, done.
>> remote: Total 384454 (delta 219550), reused 384454 (delta 219550)
>> Resolving deltas: 100% (219550/219550), done.
>> fatal: Out of memory, malloc failed (tried to allocate 440237 bytes)
>> Unlink of file 
>> 'mylocalrepo/.git/objects/pack/pack-a92fdeb2782784db447564664d98fe6
>> 7183d155c.idx' failed. Should I try again? (y/n) n
>>
>> I've tried many solutions found on forums with no luck. Could someone 
>> help me? Your help is very appreciated!
>>
>> Thanks
>> Igor
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Git for human beings" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to git-users+...@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>  
>>  
>>
>
>
>
> -- 
> This is a test of the Emergency Broadcast System. If this had been an 
> actual emergency, do you really think we'd stick around to tell you?
>
> Maranatha! <><
> John McKown
>  

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to