From: Junio C Hamano Date: Mon, 08 Sep 2025 14:43:20 GMT Subject: Re: Git dumb HTTP protocol should work without update-server-info Message-ID: In-Reply-To: Patrick Steinhardt 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. [Footnote] * ... or its equivalent generated offline and uploaded manually to the repository, which was what I did before I got an account at kernel.org. There was a small web space at local ISP provided for its subscribers, so my "push" was to ftp upload the loose objects, packs, refs, and the info/refs + objects/info/packs files there X-<.