fix(checkpoint): name the sync remote in the multi-remote note

[gtrrz-victor]

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

The problem

The several-remotes note printed by entire enable / entire doctor says:

Checkpoints sync to a single elected remote — not to whichever one you push to. A push to any other remote carries your code but no session history. Run entire status to see the elected destination and how many checkpoints are waiting for it.

That bolded sentence is not true of the one push that matters most. pendingCaptureCheckpointSyncRemote runs before the single-remote gate in prePush, so a push whose target agrees with the branch's declared push destination elects that remote and carries the checkpoints there in the same push (TestCheckpointSyncRemote_TrackedPushCapturesElection asserts exactly that). The note was warning about a case the CLI now handles by itself.

It also never said where checkpoints actually go — the one thing a user standing in a multi-remote repo wants to know.

The change

inspectRemoteTopology asks strategy.ResolveCheckpointSyncRemote for the election (never re-derived from settings — the same rule the existing pinned field follows, so the shown destination cannot diverge from where pushes go), and the note says the concrete thing. Election still open:

  This repo has 3 remotes (custom, origin, upstream).
    Checkpoints sync to one remote — right now "origin". A push to a different
    remote of your own can move it; `entire status` shows where they go.
    Set strategy_options.checkpoint_push_remote to pin one yourself.

"a different remote" rather than "your branch's own remote": capture requires the push target to both agree with the branch's declared push destination and differ from today's election, so on the ordinary setup where they already agree, no push moves anything — and the earlier wording promised a takeover that cannot happen.

Observed tier — destination settled, capture clause gone:

    Checkpoints sync to one remote — "custom", your branch's push destination.
    A push to any other remote carries your code but no session history.
    Set strategy_options.checkpoint_push_remote to pin a different one.

Explicit checkpoint_push_remote — no advice line, because repeating the key they already set reads as a warning that something still needs doing:

    Checkpoints sync to one remote — "custom" (set by checkpoint_push_remote).
    A push to any other remote carries your code but no session history.

The sentence this PR set out to delete survives on exactly these two tiers. It is untrue only where the election is still open, because there the electing push carries its own history to the remote it elects. Once checkpoint_push_remote is set or a capture is in force, captureEligible refuses every displacement, so no push can move the destination and the warning is exactly right — and it is the fact a multi-remote user most needs. Deleting it repo-wide traded one wrong sentence for a missing one.

Two more states name no remote at all. The first is a failed election — the resolver failing closed on a checkpoint_push_remote that names a remote which does not exist, or on a settings file it could not read. Checkpoints are going nowhere until that is fixed, so the error is kept on the topology rather than swallowed into a debug log, and reported in the wording entire status already uses:

    Checkpoints are NOT syncing: checkpoint_push_remote "gone" is not a configured git remote; checkpoint sync disabled until fixed

That is the only branch here that is a warning rather than orientation.

The second is an election that came back with no name and no error. An earlier revision of this PR ruled that out — with two or more remotes a successful election was said to always return a name — but the resolver's own git config read answers nil on a transient failure rather than caching it (cachedRemotesInConfigOrder), so an unnamed, error-free answer is reachable. Left silent it printed the remote count and nothing else, strictly less than the static text this replaces, so it falls back to the one clause true on every tier:

    Checkpoints sync to a single elected remote; `entire status` shows which.

The fan-out block above (one remote, several push URLs) is untouched — that one is still genuinely lossy.

The tier switch names the three open tiers instead of falling through to default: golangci-lint's exhaustive rule rejects the default clause. SyncRemoteSourceSole is all but unreachable at this call site — this note is written only when two or more remotes are unpinned, and the resolver reaches the sole tier only with exactly one remote configured — so it is grouped with the open tiers. Not asserted as impossible, though: the two sides count remotes with different git commands (git remote -v here, git config --local --get-regexp in the resolver), which can disagree, and the shared wording reads correctly either way.

Test

TestMultiPushURL_DestinationNoteSurfaces runs on the open-election tier, so it still asserts "no session history" absent there, alongside the two phrasings this note was already wrong with ("follow whichever remote", "always looks at origin"), so a future rewrite cannot reintroduce any of the three.

TestDescribeSyncRemote (new, cmd/entire/cli/remote_topology_test.go) covers every tier the note words differently — config, observed, open election by default and by first, fail-closed, and unresolved — asserting both the text that must appear and the text that must not, since the integration test only ever reaches the open-election tier. The settled tiers assert "no session history" present and the open ones assert it absent, which is where that split is pinned. describeSyncRemote is a pure function of two fields and an io.Writer, so the table is cheap.

Verification

• golangci-lint 2.11.3 ./cmd/entire/cli/... → 0 issues, gofmt clean. (An earlier revision of this PR claimed lint was clean when it was not: exhaustive was failing on the tier switch. Fixed here.)
• mise run test → 9313 tests, 4 skipped, 0 failures (186s), as of f9eb943's parent; re-run after f9eb943 was scoped to go test ./cmd/entire/cli/..., which passes.
• TestMultiPushURL (integration, all cases) and TestDescribeSyncRemote pass.
• The four states that existed at 6c71f73 were verified by hand against a 3-remote repo. The two added since — the fail-closed warning and the unresolved fallback — are covered by TestDescribeSyncRemote only, since the unresolved one needs a transient git failure to reproduce by hand.

Trail findings

One finding on trail #1108, dismissed as not applicable: it asked for separate wording for SyncRemoteSourceSole, which this call site does not reach. Recorded in a code comment instead of a fourth message.

Copilot's inline review caught the silent-return case above before the fail-closed branch landed; its second half — an unnamed election with no error — outlived that fix and is closed by f9eb943.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Updates the multi-remote checkpoint destination note (shown by entire enable / entire doctor) to name the currently elected checkpoint sync remote by querying the same resolver used by push logic, so the note reflects where checkpoints actually sync and avoids previously incorrect wording.

Changes:

• Add checkpoint sync remote + source to remoteTopology, populated via strategy.ResolveCheckpointSyncRemote.
• Replace the prior generic “no session history on other remotes” warning with tier-aware, concrete messaging that names the elected remote.
• Tighten the integration test to assert previously incorrect phrasings (including “no session history”) stay absent.

Reviewed changes

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

File	Description
cmd/entire/cli/remote_topology.go	Resolve and print the elected checkpoint sync remote in the multi-remote note.
cmd/entire/cli/integration_test/multi_pushurl_test.go	Update assertions to cover the new phrasing and prevent regressions to prior incorrect wording.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.