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

- From: Junio C Hamano \<hidden\>
- Date: 2021-01-29 23:11:57 
- List: git
- Page: https://ratatoskr.run/git/2021/01/7874562

```text
Taylor Blau [ref] 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.
```