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
Attachment:
signature.asc
Description: PGP signature
