On Fri, Jan 29, 2021 at 05:43:32PM -0500, Jeff King wrote: > So I think the paths forward are either: > > - come up with an air-tight system of making sure that we know packs > we claim are closed under reachability really are (perhaps some > marker that says "I was generated by repack -a") > > - have a "roll-up" mode that does not care about reachability at all, > and just takes any objects from a particular set of packs (plus > probably loose objects) > > I'm still thinking aloud here, and not really sure which is a better > path. I do feel like the failure modes for the second one are less > risky. The more I think about it, the more I feel that the second option is the right approach. It seems like if you were naïvely implementing this from scratch, that you'd pick the second one (i.e., have pack-objects understand a new input mode, and then make a pack based on that). I am leery that we'd be able to get the first option "right" without attaching some sort of marker to each pack, especially given how difficult I think that this is to reason about precisely. I suppose you could have a .closed file corresponding to each pack, or alternatively a $objdir/pack/pack-geometry file which specifies the same thing, but both of these feel overly restrictive. Besides having to special case the loose objects, is there any downside to doing the simpler thing here? > Anyway, here's the --unpacked example, if you're curious. It's based on > fetching, but you could invert it to do pushes (in which case it is > repacking in "parent" that gets the wrong result). Fascinating indeed :-). Thanks, Taylor
