On Mon, 11 Aug 2008, Ken Pratt wrote:

quoted text
> > As a quick workaround you could try it with a 32bit git executable?
> > (assuming you have a distribution with proper multilib support)
> 
> In this case, I do have control over the server (running Arch Linux,
> which should do 32-bit multilib just fine), but for my workflow I
> cannot assume that the server will have 32-bit git support.
> 
> I will use the previously mentioned solution of doing the packing
> elsewhere for now as a band-aid, with hopes that this will get fixed
> sometime soon.

I'm afraid no fix is "possible" since you said:

quoted text
> Largest object is ~150MB, and there are a couple 5-10MB objects as 
> well.

If you have only 256 MB of RAM, I'm afraid the machine dives into swap 
the moment it attempts to process that single 150-MB object during 
repacking.  Objects are always allocated entirely, including the 
deflated and inflated copy at some point.  Making git handle partial 
objects in memory would add complexity all over the map so I don't think 
it'll ever be implemented nor be desirable.

If you do repack once with 'git repack -a -f -d' on a bigger machine 
then 256 MB of RAM might be fine for serving clone and fetch requests 
though.


Nicolas
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html