Re: [PATCH 0/2] repack: pack everything into promisor packfile in partial repos

[Junio C Hamano <gitster@pobox.com>]

Han Young <hanyang.tony@bytedance.com> writes:

> By using 'repack everything', repacking requires less work and we are not
> using more bandwidth. The only downside is normal objects packing does not
> benefiting from the history and path based delta calculation. Majority of
> objects in a partial repo is promisor objects, so the impact of worse normal
> objects repacking is negligible.

There is an important assumption that any objects in promisor packs
*and* any objects that are (directly or indirectly) referenced by
these objects in promisor packs can safely be expunged from the
local object store because they can be later fetched again from the
promisor remote.  In that (in)famous failure case topology of the
history:

    commit  tree  blob
     C3 ---- T3 -- B3 (fetched from remote, in promisor pack)
     |
     C2 ---- T2 -- B2 (created locally, in non-promisor pack)
     |
     C1 ---- T1 -- B1 (fetched from remote, in promisor pack)

even though the objects associated with the commit C2 are created
locally, the fact that C3 in promisor pack references it alone is
sufficient for us to also assume that these "locally created" are
now refetchable from the promisor remote that gave us C3, hence it
is safe to repack the history leading to C3 and all objects involved
in the history and mark the resulting pack(s) promisor packs.

OK. That sounds workable, but aren't there downsides?

Thanks for working on this topic.