Junio C Hamano <gitster@xxxxxxxxx> writes:
>> +Multiple hooks are supported, but all must exit successfully, else no
>> +cruft pack will be generated.
>> +
>
> Now, we are told this variable refers to "hooks". If that is the
> name we want to call them, we'd better use the term from the
> beginning.
I was updating the "What's cooking" draft and here is my tentative
summary of the topic.
* tb/pack-extra-cruft-tips (2023-05-03) 1 commit
- builtin/pack-objects.c: introduce `pack.extraCruftTips`
"git pack-objects" learned to invoke a new hook program that
enumerates extra objects to be used as anchoring points to keep
otherwise unreachable objects in cruft packs.
source: <27a7f16aab35b5cac391d9831aadb0f2e2146313.1683151485.git.me@xxxxxxxxxxxx>
I think I earlier saw review comments on a side thread that
mentioned "repack -A"; when I read it I didn't quite get the point
of the discussion, but after summarizing the gist of the topic as
above, I _think_ I tend to agree. This should not be about "should
we have these extra objects in cruft pack?" but is about "should we
keep these extra objects alive and exempt from pruning". What these
extra tips tell us is that the part of the reachability graph rooted
at these extra objects should be treated as if they are reachable.
Storing them inside cruft packs may be a reasonable choice to make
today, in the sense that among various object storage mechansim, the
cruft pack mechanism may be the best fit in today's system, but it
does not have to stay that way. Naming the variable to specify the
hooks with name "cruft" in them would make it hard to explain once
we find an even better storage mechanism to store such a "not really
used but want to keep" objects.
