Taylor Blau <me@xxxxxxxxxxxx> writes: > 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). Yes, "roll-up" mode would be a sensible thing to have, as long as we can keep pruning out of the picture for now. But in the end, I do think "stop at any object in this frozen pack---these objects go all the way down to root and we know they are reachable" optimization that would give 'prune' a performance boost with small margin of false positive about reachability (i.e. we may never be able to prune away an object in such a pack, even when it becomes unreachable) would be a valuable thing to have in a practical system, so from that point of view, the work done in these patches are not lost ;-) The efficiency issue of the resulting pack I mentioned earlier in a separate message is there in the "roll-up" mode, though.
