Fix docs: target HEAD discovery is sequential, not concurrent

ac61873·

Soph·2mo ago·1 file·+6 added/-4 removed

The previous commit serialized the upload-pack info-refs after the receive-pack call to avoid a conn.Endpoint race under FollowInfoRefsRedirect, but the docs still claimed the round-trip ran concurrently. Update usage.md to match the actual behavior (one extra RTT during target setup) and the reason for the ordering.

Refs #45.

Co-Authored-By: Claude Opus 4.7 (1M context) noreply@anthropic.com

Sessions

e5ab3abb81d4View transcript

Changes

1

• docs

• Musage.md+6/-4

239 unmodified lines

240
241
242
243
244
245
246
243
244
245
246
247
248
249
250
251

239 unmodified lines

Target HEAD is read via a separate `upload-pack` info-refs round-trip
against the target URL, since the `receive-pack` advertisement we use for
push setup omits HEAD by protocol design. The round-trip runs concurrently
with the existing target setup; failures (push-only auth that 401s on
upload-pack, empty bare targets where HEAD's underlying ref doesn't yet
exist) leave `targetHead` empty rather than failing the sync.
push setup omits HEAD by protocol design. The round-trip runs after the
receive-pack call (they share the target connection, which the redirect-
following path mutates), so target setup costs one extra RTT. Failures —
push-only auth that 401s on upload-pack, empty bare targets where HEAD's
underlying ref doesn't yet exist — leave `targetHead` empty rather than
failing the sync.

The target's default branch is **not** automatically reconciled. git's
`push --mirror` doesn't propagate HEAD either; the only portable wire-level