On 5/2/07, Junio C Hamano <junkio@xxxxxxx> wrote:
Dana How <danahow@xxxxxxxxx> writes: > Consequently, for such a usage pattern it is useful > to specify different compression levels for loose > objects and packs. This patch implements a config > variable pack.compression in addition to the existing > core.compression, meant to be used for repacking. > It also adds --compression=N to pack-objects, > meant for push/pull/fetch, if different, or if different > on a per-repository basis. > > ** THIS PATCH IS UNTESTED AND MEANT FOR DISCUSSION. ** I think we tweaked this area in the past, but I do not think the current setting was determined to be the best tradeoff for all workloads. To be able to discuss the patch, I think it needs to come with benchmark numbers using publicly available repositories as guinea pigs and set of typical git operations, so people can reproduce and compare notes.
OK, but this patch doesn't mandate any particular setting. Its motivation in my work environment is for pack.compression to be what core.compression currently is, and to set core.compression to 0 to speed up large commits (the resulting space-inefficient loose objects will be scrubbed away by a later off-line repack). Thus, my config settings (almost) change the gzip's behind a git-add to cp's. Do you want me to submit timings for a git-add/git-commit -a on a typical 50-file commit I would be interested in, with the (new) settings that I would use? Thanks, -- Dana L. How danahow@xxxxxxxxx +1 650 804 5991 cell - 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