On Tue, 12 Feb 2008, Brian Downing wrote: > So that gives four options: > > 1. No memory limit, constant entry depth. Original Git behavior. > 2. The above with an additional memory-based depth limit. This is > what was added with --memory-limit. > 3. Constant entry depth with a memory-usage limit. This is what the > proposed patch does. ... and it was merged already. > 4. Dynamic entry depth, with a memory-based limit. This is I believe > what you are proposing above, and what I emulate by setting > --window=$bignum --window-memory=x. > > I'm willing to try and make all of those work. (Though frankly I don't > care much about #3; setting the window entry size to something "large > enough" seems a simple enough work-around for me, and it prevents what's > probably some truly ridiculous behavior if you have a gigantic number of > tiny, say, tree objects. Having a cap on window depth stops that case > from taking a truly inordinate amount of time.) > > However, I can't figure out what sensible command-line and/or config > parameters would be for the cases above. Any ideas? I explicitly avoided suggesting something in my previous email exactly because I don't have a clear idea myself for a sensible parameter. ;-) Maybe using a negative window size could mean it is dynamic, but caped to the provided absolute value? Although a bit strange, this is still a specialized mode of operation and having an odd argument for it shouldn't rebute those who understands the implication and are willing to use it. The more natural mode of operation with a memory cap is not to change the end result but maybe experience a slowdown (what the merged patch does), which is why I considered that patch good. 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
