Re: [PATCH 03/10] builtin/pack-objects.c: learn '--assume-kept-packs-closed'

Taylor Blau [off-list ref] writes:

On Fri, Jan 29, 2021 at 05:43:32PM -0500, Jeff King wrote:

quoted

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.