The transport layer

Git's wire protocol historically interleaves client and server messages over a stateful connection. stateless-connect (introduced for protocol v2 over HTTP) decouples requests so each is independently routable, friendlier to load balancers and HTTP/2 servers.

Stateless flows

Under stateless-connect, the client sends a self-contained request (capabilities, wants, haves, options) over a single HTTP POST. The server answers with the response. No long-lived TCP state, no per-connection negotiation rounds.

GIT_TRACE_PACKET=1 GIT_TRACE_CURL=1 \
  git -c protocol.version=2 fetch origin 2>&1 | head -50

HTTP/2 benefits

HTTP/2 multiplexing lets multiple stateless requests share one connection. Combined with v2's capability negotiation, fetches against modern servers (GitHub, GitLab) are noticeably faster — especially over high-latency links.

Tuning the HTTP layer

[http]
version = HTTP/2
postBuffer = 524288000     # 500MB; raise for large pushes
lowSpeedLimit = 1000
lowSpeedTime = 30
minSessions = 4
maxRequestBuffer = 100M

http.postBuffer matters for pushes over flaky networks; the buffer holds the request before sending, so larger means fewer retries on TCP hiccups.

Fetch parallelism

git config fetch.parallel 0
git config submodule.fetchJobs 0

Stateless requests parallelize cleanly; multiple submodule fetches go in parallel without sharing state.

Smart vs dumb HTTP

"Smart" HTTP supports negotiation (the modern path); "dumb" HTTP just serves .git/objects as static files. Always prefer smart. Configure servers to expose git-upload-pack CGI or use a forge that runs Git natively.

Common mistakes

Forcing HTTP/1.1 with http.version=HTTP/1.1 on a host that supports HTTP/2 — multiplexing wins are lost. Setting http.postBuffer very high "just in case" — it allocates per request. Believing stateless-connect changes object format; it only changes the request layer.

Diagnosing

GIT_CURL_VERBOSE=1 git fetch 2>&1 | head -30
GIT_TRACE_PACKET=1 git fetch 2>&1 | grep -i version

Related

See "Protocol v2 for efficient fetch negotiation" and "Fetch and push over large repositories".