On Wed, Oct 07, 2020 at 11:41:43AM -0700, Jonathan Tan wrote: > > We seem to have removed find_unresolved_deltas() helper function in > > that series, but there remains a mention to it in a comment, which > > we would probably should rethink (it just may be the matter of > > removing the mention, or if "just like in ..." may have been the > > last example of doing what the comment suggests all code to do, it > > may reveal a need for larger clean-up---I dunno). > > Maybe the whole comment block should be deleted and replaced with > something like: > > Ensure that this node has been uncompressed and return its contents. > > In the typical and best case, this node would already be uncompressed > (through the invocation to resolve_delta() in threaded_second_pass()) > and it would not be pruned. However, if pruning of this node was > necessary due to reaching delta_base_cache_limit, this function will > find the closest ancestor with uncompressed data that has not been > pruned (or if there is none, the ultimate base object), and uncompress > each node in the delta chain in order to generate the uncompressed data > for this node. FWIW, that is much clearer to me. Do you want to work that up as a replacement for my patch 3? > (I'm using "uncompress" here because I find the original "deflate" term > confusing - I thought that "deflate" meant compress, and thus the > "data" here would be the uncompressed form, and hence undeflated or > inflated.) Yeah, I think the original meant "inflated", not "deflated". Except that it's really more than a zlib inflate, as we probably would have reconstructed it by patching another delta. I guess you _could_ call that inflation, too, but we usually don't. Maybe "reconstructed" would be a better term to use in general (though I am happy enough with the "uncompressed" you used above). -Peff