On Wed, Aug 7, 2013 at 10:48 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes: > >> [ It's cool you're working on this, I'd really like a git-repack in C. >> That would fix this >> http://thread.gmane.org/gmane.comp.version-control.git/226458 ] >> >> Stefan Beller <stefanbeller@xxxxxxxxxxxxxx> writes: >> >>> From: Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> >>> >>> pack-objects learns a few more options to take over what's been done >>> by git-repack.sh. cmd_repack() becomes a wrapper around >>> cmd_pack_objects(). >> >> I think the patch would read easier if these were split into two >> patches: one doing the real stuff in pack-objects, and then getting rid >> of git-repack.sh to replace it with a trivial built-in. >> >> Actually, I'm wondering why pack-objects requires so much changes. >> git-repack.sh was already a relatively small wrapper around >> pack-objects, and did not need the new options you add, so why are they >> needed? In particular adding the new --update-info option that just does >> >>> + if (repack_flags & REPACK_UPDATE_INFO) >>> + update_server_info(0); >> >> seems overkill to me: why don't you just let cmd_repack call >> update_server_info(0)? > > My feeling exactly. I would rather see a patch that does not touch > pack-objects at all, and use run_command() interface to spawn it. > Once we do have to pack, the necessary processing cycle will dwarf > the fork/exec latency anyway, no? I'm not opposed to run_command(). I think the reason I wanted to move repack functionality to pack-objects is to avoid reading sha-1 from pack-objects and reconstruct the paths again from the sha-1. But for simplicity, perhaps we should not touch pack-objects at all. Then we could have builtin/repack.c instead of stuffing cmd_repack in builtin/pack-objects.c @Stefan, if you want to push this work, feel free to take it as _your_ patch, rewrite as will. You don't need to retain my name. -- Duy -- 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