Re: [PATCH 0/4] send-pack: introduce a `no-ref-delta` capability

[Jeff King <peff@peff.net>]

On Sat, Jul 18, 2026 at 04:02:40PM -0500, Taylor Blau wrote:

> > The problem there is not REF_DELTA itself, but the fact that REF_DELTA
> > allows you to place a base after the delta which depends on it.
> 
> Exactly.
> 
> > If _that_ is your main concern, would it be worth a tighter capability
> > advertisement that insists that bases come before their deltas (if they
> > are in the pack at all)? We already generate packs that way by default,
> > and it would really just give the server a license to reject these
> > non-standard packs.
> 
> That would address the ordering problem, but is weaker than the format
> restriction this receiver wants. Even a backward REF_DELTA requires an
> OID-to-entry lookup, whereas the retained pack's reconstruction metadata
> is addressed by offset alone. Supporting that is possible, of course,
> but adds another way to locate a base.

Yeah, but I don't think it's that much more complicated. You are
collecting the oids of the stuff you index anyway (since that is the
point of indexing), so it is just a matter of storing that in a
searchable data structure.

But what _is_ more complicated is the data dependency. Imagine you have
a pool of workers waiting to do delta resolution and hash computations.
You want to hand off each new object entry you parse to one of the
workers. With OFS_DELTA you know where the base is immediately, and if
its resolution is still pending, you know which worker you handed it off
to. But with REF_DELTA, you don't know which worker is processing your
base until it has finished (since that's when it reports back the oid).

That might or might not matter depending on your caching strategy for
intermediate states. For example, if you're trying to maintain locality
in what you hand to a worker (so if you have a delta chain A-B-C, when
you find C you want to give it to the worker who computed B, because
they may have that intermediate result at hand).

I do think in general that the intermediate-state caching is going to be
the trickiest part of a streaming resolution, though. Even with just
OFS_DELTA, there is no way to know in a single pass that the object at
position N is worth keeping around because N+K is going to reference it,
and K can be arbitrarily large. With Git's pack-objects implementation,
you will generally see delta families grouped together, but that's not
guaranteed.

So I'm growing more convinced that asking the client not to send
REF_DELTAs might open up some more opportunities for optimizations, but:

  1. It would be neat if we could see those optimizations in git.git's
     receiving code. ;)

  2. Without seeing the whole scheme, I am still unclear on how some of
     these other complications aren't much worse/harder.

I don't think you're asking for a lot of support on the git.git side, so
in that sense I'm not really opposed. I'm just not excited about
carrying protocol additions that wouldn't be used by git.git itself,
especially if we later find that the capability isn't a perfect match
for the optimizations we want to make.

-Peff