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

From: Jonathan Tan <[email-masked]>
Date: Mon, 25 Nov 2024 11:45:41 -0800

Junio C Hamano <[email-masked]> writes:
> Jonathan Tan <[email-masked]> writes:
> 
> > Junio C Hamano <[email-masked]> 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).  

Yes, that's correct.

> 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?

Just to be clear, this is not happening right now (blob B is sent whole,
not as a delta). But let's suppose that blob B was sent as a delta, then
yes, the lazy fetch would materialize blob A...

> 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?

...ah, in this case, blob A vouches for itself. Whenever we lazy fetch,
all objects that are fetched go into promisor packs (packfiles with an
associated .promisor file), so we know that they are promisor objects.