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

From: Junio C Hamano <gitster@pobox.com>
Date: May 3, 2023, 23:42 UTC
Message-ID: <xmqqjzxpm172.fsf@gitster.g>
In-Reply-To: <xmqqv8h9m2az.fsf@gitster.g>

Junio C Hamano <gitster@pobox.com> writes:

Show 7 quoted lines

>> +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@ttaylorr.com>

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.