test: pin down checkpoint push behavior for multi-push-URL remotes

[Soph]

https://entire.io/gh/entireio/cli/trails/970

What

A single git remote can carry several push URLs — remote.<name>.pushurl may repeat, and a repeated remote.<name>.url has the same effect. It's how people mirror to two forges in one push, or keep a backup remote. Verified behavior:

Config	Fetch	Push
remote.origin.url ×2	uses only the first	goes to both
remote.origin.pushurl ×2	uses url	goes to both pushurls

Two git facts drive everything here:

1. git push origin fans out to every push URL.
2. git invokes the pre-push hook once per push URL, passing the same remote name as $1 each time and the individual URL as $2.

Our installed hook forwards only $1 (strategy/hooks.go), so the CLI sees N identical invocations and hands git push <name> the name — letting git fan out a second time. It has no per-URL control at all: it can decide whether to push checkpoints for an invocation, not where they land.

This PR adds integration coverage for what that means, and is tests only — no production change.

Bugs documented

Both use the existing t.Skip("KNOWN BUG: …") convention (see remote_operations_test.go:625), placed so everything above the skip still enforces what works today, and the assertions after it state the desired behavior. Fixing either is a one-line deletion.

1. Divergence recovery only ever reconciles the fetch URL. When push URLs diverge independently, the rejected push triggers fetch+rebase recovery — but git fetch <remote> reads only the remote's fetch URL. URL A converges; URL B is left rejected with its divergence unmergeable. Captured hook output:

[entire] Pushing entire/checkpoints/v1 to origin...          ← rejected by both
[entire] Syncing entire/checkpoints/v1 with remote... done    ← fetched from URL A only
[entire] Pushing entire/checkpoints/v1 to origin...           ← retry
[entire] Warning: failed to push entire/checkpoints/v1 after sync: non-fast-forward

git push exits 0, so this is silent: the second mirror just stops receiving checkpoints, and the only trace is a warning that doesn't name the URL that rejected it. It also can't self-heal within the push — there is one remote-tracking ref per remote name, and git advances it to the hash the successful URL accepted, so pushRefIfNeeded's up-to-date check reports "in sync with origin" and the second hook invocation short-circuits. That mechanism is logged rather than asserted.

2. Adding a push URL defeats the empty-remote guard. deferCheckpointPushOnEmptyRemote exists because entire/checkpoints/v1 is a real refs/heads branch a forge would adopt as the default branch of an empty repo. The guard asks whether the remote name has local remote-tracking refs — it does, thanks to the established first URL — so it permits the push, and the fan-out publishes v1 into a brand-new second URL that has no branches. The hook runs before git transfers the user's branch, so v1 gets there first.

Passing coverage

• ..._Branch_FanOutToBothPushURLs / ..._Refs_FanOutToBothPushURLs — both URLs receive checkpoints, on both backends.
• ..._Branch_RepeatedPushesKeepBothURLsInSync — three sequential checkpoints, both URLs in sync with identical v1 tips. This is the property a mirror user depends on, and exists to fail loudly if checkpoint pushes are ever retargeted at a single resolved URL. That looks like a tidy way to serve a user who doesn't want checkpoints mirrored, but it silently breaks the user who configured several push URLs precisely because they do. A single destination must come from explicit config, never be inferred from topology.
• ..._Refs_UnreachableSecondPushURL_RefsStayQueued — git-refs leaves refs queued after a partially failed push instead of dropping them, so later pushes retry. This is the concrete behavioral difference from the git-branch path, which drops the failure on the floor.

An unreachable URL rather than divergence is used for the git-refs failure case on purpose: per-checkpoint refs only fast-forward and an ID is minted once, so same-ref divergence isn't reachable without a backfill or migration rewriting an existing checkpoint.

Notes for reviewers

• AddSecondPushURL re-adds the remote's original URL as an explicit pushurl before adding the new one. Configuring any pushurl replaces url for push purposes, so adding only the new one silently redirects instead of fanning out. The helper asserts it ended up with two.
• Both fan-out helpers re-baseline the .git/config guard, since changing push URLs is deliberate.
• The negative assertions aren't vacuous — the fan-out baselines prove the second URL does receive checkpoints on the happy path.

Test plan

• go test -tags=integration -run TestMultiPushURL ./cmd/entire/cli/integration_test/ — 4 pass, 2 skip
• Full integration package green; mise run fmt && mise run lint clean
• Unrelated pre-existing flake seen while validating: a spawned subprocess intermittently segfaults under -race (~1 in 3 full-package runs), hitting a different test each time. Reproduced with these files removed from the tree, so it predates this branch.

🤖 Generated with Claude Code

---

Note

Low Risk
Test-only changes with no production code; risk is limited to CI runtime and future behavior contracts when bugs are fixed.

Overview
Adds integration-only coverage for remotes with multiple push URLs (mirror/backup setups): new TestEnv helpers (AddSecondPushURL, push-queue inspection, diverged refs, GitPushWithHooksAllowError) and six TestMultiPushURL_* cases for git-branch and git-refs backends.

Passing tests lock in that checkpoint pushes go to the remote name so git fans out to every push URL, repeated pushes keep mirrors aligned, and git-refs leaves refs queued when one push URL is unreachable so later pushes retry.

Two skipped KNOWN BUG tests document desired behavior without changing production code: fetch+rebase recovery only reconciles the fetch URL when push URLs diverge independently (second mirror can stop getting checkpoints silently), and the empty-remote deferral for entire/checkpoints/v1 is bypassed when a second push URL is still empty because the guard keys off remote name tracking refs.

^{Reviewed by Cursor Bugbot for commit cbcee40. Configure here.}

[Copilot]

Pull request overview

Adds integration-only characterization coverage for git remotes configured with multiple push URLs, focusing on how the pre-push hook and checkpoint pushing behave when git push <remote> fans out across multiple destinations.

Changes:

• Introduces new TestEnv helpers for configuring multi-push-URL remotes, inducing divergence, and inspecting the git-refs push queue.
• Adds git-branch and git-refs integration tests that assert checkpoint fan-out behavior, repeated-sync behavior, and partial-failure behavior.
• Adds two t.Skip("KNOWN BUG: …") tests that document current incorrect behavior without changing production code.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
cmd/entire/cli/integration_test/multi_pushurl.go	Adds integration test helpers for multi-push-URL remotes, divergence setup, and push-queue inspection.
cmd/entire/cli/integration_test/multi_pushurl_test.go	Adds integration characterization tests for multi-push-URL remotes across git-branch and git-refs checkpoint backends, including two skipped “KNOWN BUG” tests.