Re: [PATCH 3/7] pack-objects: add GIT_TEST_FULL_NAME_HASH

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 25, 2024, 00:39 UTC
Message-ID: <xmqqjzcs87u0.fsf@gitster.g>
In-Reply-To: <20241122180144.523048-1-jonathantanmy@google.com>

Jonathan Tan <jonathantanmy@google.com> writes:

Show 9 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
>> It is sad that it is a (probably unfixable) flaw in the "promisor
>> object" concept that the "promisor object"-ness of blobA depends on
>> the lazy-fetch status of treeA.  This is not merely a test failure,
>> but it would cause blobA pruned if such a lazy fetch happens in the
>> wild and then "git gc" triggers, no?  
>
> Right now, it won't be pruned since we never prune promisor objects
> (we just concatenate all of them into one file).

Sorry, but I am lost. In the scenario discussed, you have two commits A and B with their trees and blobs. You initially only have commit A because the partial clone is done with "tree:0". Then you fetch commit B (A's child), tree B in non-delta form, and blob B contained within tree B. Due to the tweak in the name hash function, we do not know of tree A (we used to learn about it because tree B was sent as a delta against it with the old name hash). If blob B was sent as a delta against blob A, lazy fetch would later materialize blob A even if you do not still have tree A, no?

I thought the story was that we would not know who refers to blobA when treeA hasn't been lazily fetched, hence we cannot tell if blobA is a "promisor object" to begin with, no?

The blob in such a scenario may be reclaimed by GC and we may still be able to refetch from the promisor, so it may not be the end of the world, but feels suboptimal.