muse push — have-negotiation ignores sibling refs on remote

Background

When pushing a branch to a remote, the push negotiation computes blobs_to_send by comparing the local tip against the remote's tip for that specific branch only. It does not account for objects already present on the remote via other refs.

Observed behaviour

After pushing dev to staging successfully (17 commits, 46 blobs), pushing main to the same staging remote attempted to upload 1,375 commits and 379 MB of data — failing with [Errno 32] Broken pipe.

Local main is staging/dev + one merge commit. The merge-base of local main and local dev is exactly dev's tip (sha256:f9828e…). All objects are already present on staging from the dev push. Only the merge commit itself needs to go over the wire.

Root cause

The "have" set used during push negotiation is scoped to the target branch's remote tip. Objects reachable from other remote refs (e.g. staging/dev) are not included in the have set, so the delta computation over-counts blobs_to_send by treating already-uploaded objects as missing.

Expected behaviour

blobs_to_send should be computed against the union of all objects reachable from all refs present on the remote — not just the branch being pushed. When main is a direct descendant of dev and dev is already on the remote, the push for main should send only the new commits and their net-new objects (in this case, one merge commit and zero new blobs).

Impact

• Pushes to branches that lag behind a sibling ref on the same remote become disproportionately large.
• Large packs time out or hit broken-pipe errors even when no new data is needed.
• Workaround: push the most-advanced branch first (e.g. dev), then accept that main may still require a large redundant upload until this is fixed.