Nicolas Pitre <nico@xxxxxxx> writes: > Let's see what happens here even before any packing is attempted > > |$ git rev-list --objects 492c2e4..9404ef0 > |362 > | > |$ git rev-list --objects --all \ > | --unpacked=pack-6a3438b2702be06697023d80b77e67a73a0b0b5c.pack | > | wc -l > |26559 > > So this --unpacked= argument (which undocumented semantics I still have > issues with) is certainly not doing what is expected. The output from rev-list is not surprising. --unpacked=$this.pack implies the usual --unpacked behaviour (i.e. only show unpacked objects by not traversing into commits that are packed) and at the same time pretends that objects in $this.pack are loose. It was meant to be used for a partial incremental repacking. If you have a pack to be kept (perhaps a highly packed deep pack that holds the earlier parts of the history), marked with .keep, and a handful young packs, you would give these young ones with --unpacked, so that the resulting single pack contains all that are loose or in these young packs. After that, you can remove all the young packs and loose objects. At least that is the idea. I am not sure where that rev-list experiment you showed fits in the bigger picture, but if that is used for repacking the young packs, perhaps the issue is that after the repacking the code forgets to remove the young ones whose objects are now moved into the new pack? -- 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
