Re: [ANNOUNCE] Git v2.29.0-rc0

[Jeff King <peff@peff.net>]

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