Git development
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Taylor Blau <ttaylorr@openai.com>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH 0/4] send-pack: introduce a `no-ref-delta` capability
Date: Tue, 14 Jul 2026 03:45:06 -0400	[thread overview]
Message-ID: <20260714074506.GD4058320@coredump.intra.peff.net> (raw)
In-Reply-To: <alQ7U8TOWjhasaWk@com-79390>

On Sun, Jul 12, 2026 at 06:11:47PM -0700, Taylor Blau wrote:

> Some 'receive-pack' implementations may wish to retain the incoming pack
> without first building an object ID index, in which case requiring delta
> bases to appear earlier in the same pack makes them easier to locate.

This explanation puzzles me. OK, I can see why you might want to take in
the incoming pack and then sit on it for a bit. But surely you are not
going to update refs without seeing what's in the pack, right? Otherwise
any pushing client can corrupt your repo.

And the only way to know what's in the pack is to index it. At which
point resolving REF_DELTAs is the least of your worries there.

So I have the feeling that there's some ulterior motive, or that this is
part of a larger system, but I don't quite understand what it is. And so
it's hard to say whether this is a sensible approach.

> Bitmap pack reuse is different, since it copies entries directly from
> an existing pack. Under `--no-ref-delta`, it must inspect candidate
> objects individually, omit `REF_DELTA` entries from direct pack reuse,
> and leave them to the normal object-writing path.

Hmm. We wouldn't normally expect verbatim pack-reuse to kick in, since
this is about the client sending to the server. But OK, we certainly
need to make sure that path remains correct.

>  - The final patch advertises and consumes the new `no-ref-delta`
>    capability.

What about thin packs? They'll result in REF_DELTAs on the server once
the pack is completed/indexed. I guess we have the "no-thin" capability,
but I don't think our receive-pack implementation support sending it. I
also wouldn't be terribly surprised if not every client implementation
supports it (it was added in 2013 I think to support libgit2). But I
guess that is also true of your new no-ref-delta; only updated clients
will respect it.

What will/should a server do when they get a ref delta anyway? That
again goes back to the question of: why don't we want ref deltas?

-Peff

  parent reply	other threads:[~2026-07-14  7:45 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-13  1:11 [PATCH 0/4] send-pack: introduce a `no-ref-delta` capability Taylor Blau
2026-07-13  1:14 ` Taylor Blau
2026-07-14  7:45 ` Jeff King [this message]
2026-07-14 21:58   ` Taylor Blau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260714074506.GD4058320@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=ttaylorr@openai.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox