Re: [PATCH 2/2] repack: repack promisor objects if -a or -A is set

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 8, 2018, 00:25 UTC
Message-ID: <xmqqy3dhiu08.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20180807232304.181764-1-jonathantanmy@google.com>

Jonathan Tan <jonathantanmy@google.com> writes:

Show 10 quoted lines

>> each other [*1*], so listing them in the offset order (with made-up
>> pathname information to _force_ that objects that live close
>> together in the original pack are grouped together by getting
>> similar names) might give us a better than horrible deltification.
>> I dunno.
>
> Before I write the NEEDSWORK comment, just to clarify - do you mean
> better than horrible object locality? I think deltification still occurs
> because pack-objects sorts the input when doing the windowed
> deltification, for example:

But what to delta against what else is determined by the pathname info, which is now lost by enumerating objects without tree/history walking. By giving phoney pathnames to objects while enumerating them in offset order and giving similar pathnames to objects closer to each other, I was hoping that better bases will likely to be in the same window. The order in which objects are prepared and fed to try_delta() is "group by type, and then sort by path-hash (major key) and size (descending order, used as minor key)", so that the largest among similarly named blobs is stored as base and other blobs with similar name try to become delta against that one.

>   git rev-parse HEAD:fetch-pack.c HEAD HEAD^ HEAD^^ \
> 	HEAD^^^ v2.17.0:fetch-pack.c | git pack-objects --window=2 abc
>
> produces a packfile with a delta, as checked by `verify-pack -v`.

Is that interesting? You can make the same argument that fast-import produces a packfile with a delta.

It is known to produce horrible delta---its delta base selection essentially is "you are giving me a new object? let me see if it deltas well with the object you gave me immediately before that (and nothing else)".