On Sat, 2 Sep 2006, Junio C Hamano wrote: > > repack without -a essentially boils down to: > > rev-list --objects --all --unpacked | > pack-objects $new_pack > > which picks up all live loose objects and create a new pack. > > If rev-list had an extention that lets you say > > rev-list --objects --all --unpacked=$active_pack | > pack-objects $new_pack I have to say, that adding another pack-objects-specific flag to rev-list doesn't necessarily strike me as very nice. It might be much better to just teach "git pack-objects" to walk the object list by hand. The whole "git-rev-list | git-pack-objects" approach made more sense back when git-rev-list was the _only_ think listing objects, but now that we've librarized the whole object listing thing, maybe it's time to avoid the pipeline and just do it inside the packer logic. Of course, having git-pack-objects be able to take input from stdin is still useful, but I'd rather start moving the obviously packing-specific flags out of git-rev-list, and into git-pack-objects instead. [ That would also potentially make packing more efficient - right now the "phase 1" of packing is literally to just figure out the type and the size of the object, in order to sort the object list. So when you do a big repack, first "git-rev-list" ends up doing all this work, and then "git-pack-object" ends up _redoing_ some of it. Especially for tree objects (which are one of the most common kinds), we already opened the object once when we traversed it, so opening it again just to look at its size is kind of sad.. ] We also used to have a bug with repacking, where a git-rev-list that died with a failure would silently cause a "good" repack to happen because it had fed git-pack-objects an incomplete list of objects. Junio fixed that with a hack, but if we did all the object listing inside git-pack-objects, we'd not need that kind of things at all.. Hmm? Comments? Linus -- VGER BF report: U 0.500053 - 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