Junio C Hamano <gitster@xxxxxxxxx> writes: > 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). 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.
