On Thu, 10 Oct 2013 11:19:27 -0400
wor...@alum.mit.edu (Dale R. Worley) wrote:
> > > pack.packsizelimit=2g
> > > pack.threads=1
> > > pack.windowmemory=256m
> > 2. I'd say the pack.packSizeLimit should not affect the packing
> > behaviour -- at least that's what I gather from the manual page.
> The git-config manual page says:
> [...] The default is unlimited.
> So it seems to me that it is unlikely that pack.packsizeLimit is
> affecting memory usage.
I were referring to another bit of this block: "The maximum size of a
pack. This setting only affects packing to a file when repacking".
In my eyes, it speaks about the size of a pack file.
> On the other hand, the only repository I have that has had memory
> problems being repacked is configured:
> windowMemory = 500m
> Is it possible that "pack.packsizelimit=2g" is causing the Git code to
> process in a different manner, one in which Git allocates 2G of
> It would be simple to test whether removing that parameter fixes the
But if the default limit is no limit, by extension, attempting to clone
with this setting missing should result in malloc()'ing an even larger
amount of memory. ;-)
Well, yeah, we're plainly guessing so yes, of course cloning with that
parameter removed is worth a try.
But I suspect that the OP did a creative citation and the error is in
fact generated on the sending side. Just a hunch, I'm not sure.
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
For more options, visit https://groups.google.com/groups/opt_out.