From: "brian m. carlson" <sandals@crustytoothpaste•net>
To: Milan Hauth <milahu@gmail•com>
Cc: git@vger•kernel.org
Subject: Re: Git dumb HTTP protocol should work without update-server-info
Date: Sun, 7 Sep 2025 15:07:11 +0000 [thread overview]
Message-ID: <aL2fn4j5uhrVWrDp@fruit.crustytoothpaste.net> (raw)
In-Reply-To: <CAGiEHCtP29bQRsEyLabNrLuiP96P-o7EEGi88B7pJbP0tfprxw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2013 bytes --]
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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
next prev parent reply other threads:[~2025-09-07 15:07 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-07 11:24 Git dumb HTTP protocol should work without update-server-info Milan Hauth
2025-09-07 15:07 ` brian m. carlson [this message]
2025-09-07 17:23 ` Milan Hauth
2025-09-07 17:42 ` brian m. carlson
2025-09-08 9:40 ` Patrick Steinhardt
2025-09-08 14:43 ` Junio C Hamano
2025-09-09 5:26 ` Patrick Steinhardt
2025-09-08 0:05 ` Jeff King
2025-09-08 4:14 ` Junio C Hamano
2025-09-08 21:27 ` brian m. carlson
2025-09-09 1:35 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aL2fn4j5uhrVWrDp@fruit.crustytoothpaste.net \
--to=sandals@crustytoothpaste$(echo .)net \
--cc=git@vger$(echo .)kernel.org \
--cc=milahu@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox