On Fri, 4 May 2007, Dana How wrote: > On 5/4/07, Nicolas Pitre <nico@xxxxxxx> wrote: > > On Thu, 3 May 2007, Junio C Hamano wrote: > > > > > "Dana How" <danahow@xxxxxxxxx> writes: > > > > > > > So for a 25% increase in blob size I get 33% less elapsed time > > > > in git-add, all by changing core.compression from -1 to 1. > > > > I'll definitely take that improvement. [For the compressible files > > > > we typically have, using 0 is a bad idea: the CPU "advantage" > > > > is swamped out by the time to write a much larger file.] > > > > > > The above number is about loose objects, right? > > > > > > > Since I don't care [to the same degree] about the responsiveness of > > > > packing, I'd rather pack with -1 or better to keep packs small. > > > > > > I see. You are saying that the fact that core.compression is > > > used also for packing makes the variable less useful. > > > > I think that would make sense to have separate configs for pack and > > loose object compression. When not specified they should simply default > > to core.compression if it exists. Otherwise I'd suggest that pack > > compression default level be Z_DEFAULT_COMPRESSION and loose object > > compression default level be Z_BEST_SPEED. This would make interactive > > operations like git-add and git-commit even faster by default. > > I agree with your Z_BEST_SPEED idea. I did not include it in > the patch b/c I didn't want to change any behavior in the absence > of new config settings. > > Are you actually arguing for *3* different compression-related config > variables? Yes. > How about: > (a) core.compression controls loose objects. defaults to Z_BEST_SPEED. > (b) pack.compression controls packing. defaults to Z_DEFAULT_COMPRESSION > if neither variable exists. defaults to core.compression if only that exists Yes, although I wouldn't default pack.compression to core.compression if pack.compression doesn't exist. The documentation about core.compression currently talks (wrongly) only about loose objects anyway, so making pack.compression stand on its own won't be that bad. 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