Re: [PATCH v2] builtin/pack-objects.c: introduce `pack.extraCruftTips`

> > OK, I understand the use case you're trying to support, and your
> > approach mostly makes sense. But there are two things I was surprised by
> > in the implementation:
> >
> >   1. Does this need to be tied to cruft packs? The same logic would
> >      apply to "repack -A" which turns objects loose (of course you
> >      probably don't want to do that in the long term for performance
> >      reasons, but it's conceptually the same thing; see below).
> >
> >   2. Why is there a separate walk distinct from the one that rescues
> >      recent-but-unreachable objects?
> 
> > Conceptually it seems to me that the simplest and most flexible way to
> > think of this new feature is: pretend these objects are recent enough to
> > be kept in the grace period, even though their mtimes do not qualify".
> >
> > And then everything else would just fall out naturally. Am I missing
> > something?
> 
> I originally shied away from it, thinking that I wouldn't want to do an
> expensive walk with all of the recent objects during a non-pruning
> repack.
>
> The two code paths are quite different in practice. In the pruning case,
> we add only new objects from the kept packs and then start our traversal
> there. In the non-pruning case, we just do
> `add_objects_in_unpacked_packs()` which is really just a call to
> `for_each_packed_object()`.

> So it gets tricky when you have a pack.extraCruftTips program and want
> to invoke it in a non-pruning case. You could do something like:
> 
>   - call enumerate_and_traverse_cruft_objects() *always*, either because
>     we were doing a pruning GC, or calling it after
>     `enumerate_cruft_objects()` (in the non-pruning case)
> 
>   - ensure that enumerate_and_traverse_cruft_objects() is a noop when
>     (a) cruft_expiration is set to zero, and (b) there are no
>     pack.extraCruftTips programs specified