Re: Git dumb HTTP protocol should work without update-server-info
- From
Patrick Steinhardt <ps@pks.im>
- Date
- Sep 9, 2025, 05:26 UTC
- Message-ID
- <aL-6fPzaOhGpUafK@pks.im>
- In-Reply-To
- <xmqqy0qpxawn.fsf@gitster.g>
On Mon, Sep 08, 2025 at 07:43:20AM -0700, Junio C Hamano wrote:
Show 29 quoted lines
> Patrick Steinhardt <ps@pks.im> writes: > > > On Sun, Sep 07, 2025 at 03:07:11PM +0000, brian m. carlson wrote: > >> I will also note that the dumb HTTP protocol doesn't work with reftable > >> and there was some suggestion of removing it for Git 3.0. It certainly > >> will not work out of the box with Git 3.0, since the default is > >> reftable. > > > > Yes, indeed. In theory though reftables could also be the solution to > > the underlying issue: the client can be tought to read the "tables.list" > > file and then fetch all tables listed therein. The result would be fully > > consistent, unless any of the tables gets garbage collected. The client > > would notice and abort the operation, after which it could restart the > > operation. > > > > In that case there would be no need for git-update-server-info(1) > > anymore. The "tables.list" file sits in a well-known location, > > identifies all other tables we have to download, and there are no > > atomicity issues anymore. > > Does tables.list list what pack files there are in the repository? > I somehow doubt it. > > The dumb HTTP transport was meant to be able to operate with a truly > dumb HTTP server, that does not even have to support WebDAV at all, > so there needs some tables at known name that lists _all_ the files > the cloners are expected to be able to download from. We still need > the output from update-server-info [*] to tell what packs are there > even if tables.list is stored at the known path.
Oh, you're right. I only remembered that we need it for refs, but of course we also need it for packs.
Patrick