Checkpoint Sync Remote Configuration Fix

That message comes from the pre-push hook's sync gate in cmd/entire/cli/strategy/checkpoint_sync_remote.go:161-217. Checkpoints are only ever pushed to one remote per clone, the "checkpoint sync remote". This push went to origin, but in that clone the elected sync remote is github. The hook skipped syncing checkpoints and told you that 10 of them are waiting for a push to github.

Why github and not origin: election normally defaults to origin when it exists (ResolveCheckpointSyncRemote, line 74). The hint, though, only prints when the election was automatic, not set explicitly through checkpoint_push_remote. So github almost certainly came from the "observed" tier (checkpoint_sync_capture.go). Some earlier push went to github while the current branch declared github as its push destination (via branch.<name>.pushRemote, remote.pushDefault, or branch.<name>.remote). That push delivered checkpoints, so github was recorded in .git/entire-checkpoint-sync-remotes.json. You'd have seen "Checkpoints now sync to "github"…" at the time. The first capture sticks: later pushes to other remotes never take it over.

Why the hint fires now: the branch you're on declares origin as its push destination, and origin isn't the elected remote, so the gate blocks it. The hint deliberately only shows for a branch's declared destination, not one-off pushes like git push heroku. The idea is to tell you that checkpoints are stuck rather than silently leaving them local.

To check in entire.io-2:

Fixes, depending on which remote should get the transcripts:

• Checkpoints belong on origin: set "strategy_options": {"checkpoint_push_remote": "origin"} in .entire/settings.local.json, as the message says. Deleting the captured-state file also works, since election then falls back to origin as the default.
• They belong on github: run git push github once and they'll sync. You can also pin github in the setting to silence the hint.

A minor wart: the hint also prints when git push reports "Everything up-to-date". It runs in pre-push regardless of whether any branch refs move, so it repeats on every push to origin until you change something.

This explains the message. Your output was cut off by the pager (the : at the end), but the rest can be worked out.

What happened in that clone:

• Almost every branch tracks github. So when origin was still the default sync remote, some push to github matched its branch's declared destination and delivered checkpoints. That captured github as the sync remote, and the capture is permanent ("first capture sticks").
• The branch you just pushed from must track origin (probably set with git push -u origin), or the hint wouldn't have fired. Run git rev-parse --abbrev-ref @{u} to confirm.
• So the hook sees a push to the branch's declared destination (origin) that isn't the elected remote (github). It holds the checkpoints back and tells you so.

Does it matter? Mostly no, because both remotes end up at the same GitHub repo:

• github is git@github.com:entirehq/entire.io.git directly.
• origin is entire://aws-eu-central-1.entire.io/gh/entirehq/entire.io, the Entire mirror of that repo. Entire mirrors forward pushes through to GitHub.

The 10 checkpoints aren't lost. They're local and will go out on your next git push github. The only real risk is a branch that only ever pushes to origin: its checkpoints would sit locally until some other branch pushes to github.

Pick one:

1. Keep github (least change): run git branch --set-upstream-to=github/<branch> on the odd branch so it matches the others, then git push github once. The hint goes away.
2. Send everything through the Entire mirror: put {"strategy_options":{"checkpoint_push_remote":"origin"}} in .entire/settings.local.json. But almost all your branches push to github, so checkpoints would then stall on those pushes instead. It's only worth it if you're moving the whole clone to origin.
3. Pin github explicitly: set checkpoint_push_remote to github. Behaviour stays the same, but the hint is silenced for good. The catch is that pushes to origin will then hold checkpoints back silently.

I'd go with option 1.

On our side, the wording is misleading for this setup. "This push does not carry them" reads like data loss, when origin and github are the same repo. The hint also fires on a no-op push ("Everything up-to-date"). Both are worth fixing; I can look into them if you want.

Yes, and it fits the current design.

Why it's safe: the gate exists so transcripts don't leak to a remote that wasn't chosen for them (git push heroku, a one-off git push upstream). In your case github and origin aren't different audiences. One is git@github.com:entirehq/entire.io and the other is entire://…/gh/entirehq/entire.io, which parses to the same forge, owner and repo. Checkpoints already go through entire:// mirrors in other paths (checkpoint/remote/util.go:855, #1732), so the transport works.

Proposed change:

1. Gate (checkpointSyncAllowedForRemote, checkpoint_sync_remote.go:127): also let the push through when the push remote and the elected remote are the same upstream repo. Both must parse via gitremote.ParseURL and have the same known forge (UpstreamHost() ok), with owner/repo compared case-insensitively for GitHub. Then git push origin carries the checkpoints and nothing is left waiting.
2. Election stays as it is. github remains the elected remote; the equivalence only widens what the gate admits. Capture, the read paths (CheckpointReadRemotes) and the "first capture sticks" rule are unchanged.
3. Hint: once the gate admits it, the hint can't fire for this case. Separately, I'd suppress it when no branch refs actually move (your "Everything up-to-date" case).

Conservative edges:

• If either URL is unparseable, a file:// path, an unknown forge, or an Entire-native et/ repo against a different forge, it's not equivalent and the gate behaves as today.
• If either remote has a separate pushurl, compare push URLs as well, because that's where the data actually goes.
• With the git-branch backend, refs/remotes/github/entire/checkpoints/v1 goes stale after a push through origin. The next push to github then finds the ref already there, so it's a no-op and only the local count is briefly off. With the git-refs backend the push queue is shared, so it drains either way.

One open question: data residency. Pushing through the EU-cell mirror stores the checkpoint refs in Entire's cell as well as on GitHub. If the mirror already syncs everything from GitHub (including entire/checkpoints/v1 / refs/entire/*), nothing changes in practice. If it only mirrors branches, this would newly put transcripts in the cell. I can't confirm which from the CLI code; someone who knows the mirror's ref sync should.

Should I implement it, with the gate tests (same repo admitted; different owner, different forge and native repo rejected) and the no-op-push hint fix?

I've changed the pre-push check so a push to origin now carries the checkpoints whenever origin and the chosen sync remote are the same GitHub repository. In dip's clone, git push to the entire://…/gh/entirehq/entire.io mirror would push the waiting checkpoints too, and the "waiting to sync" message goes away. It's on branch soph/mirror-equivalent-sync-remote, not committed yet.

What changed (cmd/entire/cli/strategy/checkpoint_sync_remote.go): checkpointSyncAllowedForRemote still allows the elected remote as before. It now also allows a push remote when pushesToSameForgeRepository finds both remotes land in the same repository. The match is deliberately strict:

• Both must be configured remotes, so a push to a raw URL stays blocked.
• Every push URL on both remotes is checked, including pushurl overrides and remotes with several push URLs, and all must name one repository.
• The host must be a known forge (today only GitHub). Owner and repo are compared ignoring case.
• These never match:
  • unknown or self-hosted hosts
  • SSH host aliases like github-work
  • Entire-native et/ repos, even the same repo in two cells
  • mirrors of a different owner or repo

Nothing else changes: github stays the elected remote, and the "first capture sticks" rule and the read paths are untouched. It also applies when checkpoint_push_remote is set explicitly, since that setting names a remote and both remotes reach the same repo.

Tests: I added TestCheckpointSyncAllowedForRemote_SameForgeRepository with 4 allowed and 11 rejected cases. I checked them by mutation: removing the repo comparison, the known-forge check, or the per-URL agreement check each makes the matching tests fail. Two gaps turned up and are fixed: the known-forge check had no test, and the multi-URL test only passed because of URL order. mise run fmt and mise run lint are clean (0 issues), GOOS=windows go vet on the package passes, and the full strategy package and docs/development tests pass. I haven't run mise run check, which is required before committing.

I also updated README.md (Checkpoint Remote section) and docs/development/checkpoint-implementation.md, which both said any other remote never carries checkpoints.

I dropped the "Everything up-to-date" fix. The message can no longer appear for this mirror setup, and suppressing it in general would need the pre-push ref list passed into the hook, which it isn't today.

Dip only needs a CLI build with this change; no settings or config changes.

Should I run mise run check, commit, and open a PR?

PR is up. The repo's rule is to check trail findings after a push: