Re: Git dumb HTTP protocol should work without update-server-info

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 8, 2025, 14:43 UTC
Message-ID: <xmqqy0qpxawn.fsf@gitster.g>
In-Reply-To: <aL6kevExmhesoEWN@pks.im>

Patrick Steinhardt <ps@pks.im> writes:

Show 17 quoted lines

> 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-<.