Jonathan Tan <jonathantanmy@xxxxxxxxxx> writes: > Junio C Hamano <gitster@xxxxxxxxx> 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.
