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

[Junio C Hamano <gitster@pobox.com>]

Jonathan Tan <jonathantanmy@google.com> writes:

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