From: Jeff King <peff@peff•net>
To: Patrick Steinhardt <ps@pks•im>
Cc: Junio C Hamano <gitster@pobox•com>,
git@vger•kernel.org, slonkazoid <slonkazoid@slonk•ing>
Subject: Re: [PATCH] http: handle absolute-path alternates from server root
Date: Fri, 22 May 2026 00:55:03 -0400 [thread overview]
Message-ID: <20260522045503.GB861761@coredump.intra.peff.net> (raw)
In-Reply-To: <ag7xbkTF11N22waX@pks.im>
On Thu, May 21, 2026 at 01:50:06PM +0200, Patrick Steinhardt wrote:
> > Packfile URIs help with the actual pack generation (even if we're
> > blitting out bits from the disk with verbatim packfile reuse, we still
> > have to handle gaps and compute the checksum over the output pack).
> >
> > But it doesn't help with the server computing the set of objects the
> > client needs in the first place. IIRC, packfile URIs work by the server
> > saying "oh, I was going to send you object XYZ, but you can get it from
> > this stable pack instead". So the server still has to compute the set of
> > objects (and send any that are not mentioned in URI packs). Bitmaps
> > help, but there's still non-trivial computation and storage on the
> > server.
>
> I guess it depends on the actual server-side implementation, but in the
> general case this is of course true. A server could decide to for
> example overserve objects in case the client does a full clone, or it
> could arrange packfiles in a special way that allows it to serve at
> least some kinds of requests efficiently.
True, though you still have to receive the client wants/haves before
getting to the packfile-uri phase. The alternative is for the server
send URIs during the ref advertisement. But we have that, too, these
days: the bundle-uri feature. (Which I completely forgot about while
writing my earlier email).
So I do think that bundle-uris can probably be an adequate substitute
for dumb-http in terms of reducing server load. Though...
> Packfile URIs definitely need some love to become feasible, yes, and I
> don't think they have evolved much since their introduction. I still
> feel like they are the better mechanism for offloading traffic compared
> to bundle URIs though, as we already have packfiles around anyway.
...yeah, I agree that storing both bundles and packs can be annoying for
a server, depending on your setup. In theory it would not be hard for a
slightly-clever server endpoint to store packfiles for regular Git to
use, and then generate the bundles on the fly by cat-ing the bundle
header and the packfile, both of which can be sent out as raw bytes
without further processing.
Anyway, we are far afield from the patch that started this thread. ;) I
do agree with the general notion that we _should_ be able to get
smart-http close to the server-side expense of dumb-http with a few
tricks like these.
-Peff
prev parent reply other threads:[~2026-05-22 4:55 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-12 16:26 [PATCH] http: handle absolute-path alternates from server root Jeff King
2026-05-13 1:10 ` Junio C Hamano
2026-05-13 18:58 ` Jeff King
2026-05-15 7:41 ` Patrick Steinhardt
2026-05-15 17:01 ` Jeff King
2026-05-21 11:50 ` Patrick Steinhardt
2026-05-22 4:55 ` Jeff King [this message]
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=20260522045503.GB861761@coredump.intra.peff.net \
--to=peff@peff$(echo .)net \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=ps@pks$(echo .)im \
--cc=slonkazoid@slonk$(echo .)ing \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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