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

From: "brian m. carlson" <[email-masked]>
Date: Sun, 7 Sep 2025 15:07:11 +0000

On 2025-09-07 at 11:24:13, Milan Hauth wrote:
> this works:
> 
> git ls-remote /path/to/repo2/
> git ls-remote /path/to/repo2/.git/
> git ls-remote file:///path/to/repo2/
> git ls-remote file:///path/to/repo2/.git/
> 
> this fails:
> 
> python -m http.server -d /path/to/repo2/ &
> git ls-remote http://localhost:8000/
> git ls-remote http://localhost:8000/.git/
> 
> workaround:
> 
> pushd /path/to/repo2/.git/
> git --bare update-server-info
> mv hooks/post-update.sample hooks/post-update
> popd
> git ls-remote http://localhost:8000/
> 
> expected:
> dumb http remotes should behave like file remotes

In general, that's not possible, because HTTP doesn't support native
atomic operations.  An HTTP push locks the remote with DAV by preventing
other changes to `info/refs`, which makes the operation atomic.  If
that file isn't there, then there's no way to guarantee that the ref
update isn't competing with others, which might cause data loss.

In addition, HTTP also doesn't support native machine-readable directory
listings except with DAV.  However, we don't require DAV for fetches, so
we need a list of the refs and the packs in order to be able to download
objects correctly.

> > git --bare update-server-info
> 
> that command creates the file
> /path/to/repo2/.git/info/refs
> but that is just an optimization
> for http servers with high latency
> 
> my "dumb" http server
> is smart enough to handle http range requests
> so there is no need
> to download all the files from .git/
> 
> but also without http range requests
> this should "just work"
> and the user should be responsible for optimizations

As I said above, I don't think that's the concern here.

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.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA