entire enable` creates empty orphan `entire/checkpoints/v1` instead of fetching from configured `checkpoint_remote`

[stackptr]

What happened?

When entire enable is run on a second device in a repo that already has a checkpoint_remote configured and an existing entire/checkpoints/v1 branch in that remote, it creates a fresh empty orphan branch locally rather than fetching the existing one. This makes entire checkpoint list return no results, and a subsequent git fetch from the checkpoint remote is rejected as non-fast-forward because the local orphan has a different history.

Steps to reproduce

1. Enable Entire on device A with a checkpoint_remote configured in .entire/settings.json
2. Commit and push — checkpoint data is written to the checkpoint remote's entire/checkpoints/v1 branch
3. Clone or pull the repo on device B
4. Run entire enable -y --agent claude-code on device B
5. Run entire checkpoint list — shows 0 checkpoints
6. Attempt to fetch: git fetch https://github.com/<org>/checkpoints entire/checkpoints/v1:entire/checkpoints/v1 — rejected as non-fast-forward

Expected behaviour

entire enable should detect that a checkpoint_remote is configured and that entire/checkpoints/v1 already exists there, and fetch it locally instead of creating an empty orphan branch.

Actual behaviour

A fresh empty orphan entire/checkpoints/v1 is created locally, conflicting with the real branch in the checkpoint remote. The workaround is:

git fetch https://github.com/<org>/checkpoints entire/checkpoints/v1:entire/checkpoints/v1 --force

Entire CLI version

Entire CLI 0.6.3 (refs/tags/v0.6.3) Go version: go1.26.3 OS/Arch: darwin/arm64

OS and architecture

Darwin 25.5.0 arm64 Darwin / Linux 6.18.26 x86_64 GNU/Linux

Agent

Claude Code

Terminal

cmux

Logs / debug output

Additional context

I setup entire in my NixOS flake here, which contains .entire/settings.json and other configuration: stackptr/rc#502

[Soph]

Thanks for reporting this, we should have a fix in the next release.

[peyton-alt]

Heads-up on scope as this closes: PR #1719 fixes this for the git-branch backend (the backend this was reported on) — enable now fetches/heals entire/checkpoints/v1 from the configured checkpoint_remote instead of minting a divergent orphan.

The same user story under the git-refs backend (per-checkpoint refs; checkpoint list on a second device can't discover them because listing never enumerates the remote) is tracked separately in #1770 — it's a storage-layer discovery change, not a branch-bootstrap change, and needs to land before git-refs becomes the default primary.