On Mon, 11 Aug 2008, Ken Pratt wrote: > > 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: > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
