Skip to main content
Entire uploads checkpoints to one place, the checkpoint destination. It is either:
  • One of your existing remotes, chosen automatically or pinned with --checkpoint-push-remote <remote-name>. Checkpoints are uploaded when you run git push to that remote.
  • A separate checkpoint repository, set with --checkpoint-remote. See Store Checkpoints in Another Repository.
The two flags differ by one word but mean different things: --checkpoint-push-remote picks which of your remotes receives checkpoints, while --checkpoint-remote sends them to a different repository altogether. entire status shows the current destination, where it came from, and how many checkpoints are unpushed. With the default git-refs storage backend, entire checkpoint list --outgoing lists them. Every entire enable run ends by naming the destination.

​
Which Remote Receives Checkpoints

If you push code to several remotes, checkpoints go to exactly one of them. Entire picks it in this order:
  1. strategy_options.checkpoint_push_remote, if set. If it names a remote that isn’t configured, checkpoints don’t sync.
  2. The remote of your first push whose target matches the branch’s configured push destination. Entire announces the choice and keeps it.
  3. origin
  4. The sole remote, if the repository has exactly one
  5. The first remote in .git/config order
A push to any other remote carries no checkpoint data, unless every push URL of both remotes names the same GitHub repository. For example, git@github.com:acme/widgets.git and its Entire mirror entire://<cluster>/gh/acme/widgets reach the same repository, so a push to either carries the checkpoints.

​
Choose the Remote

When a repository has several remotes that could receive checkpoints, the first interactive entire enable asks which one to use, after agent selection and before any hooks or settings are written. Running entire enable again in an enabled repository does not ask again. Choosing a remote saves strategy_options.checkpoint_push_remote in .entire/settings.local.json, so teammates do not inherit a remote name specific to your clone. Keeping the current destination writes nothing. To select a remote without the picker:
The remote must already exist. Use the same command to change the destination later, or to repair a saved selection that names a missing remote. An explicit flag pins the named remote, even if it is currently selected automatically. --yes alone does not change the destination. Selecting a destination does not re-enable disabled checkpoint pushing, upload existing checkpoints immediately, or move or delete checkpoint history on other remotes.

​
Edge Cases

  • An SSH host alias from ~/.ssh/config, such as git@github-work:acme/widgets.git, counts as GitHub when Git runs plain ssh. With a custom GIT_SSH_COMMAND or core.sshCommand, the alias cannot be resolved, so it does not match.
  • entire enable always says where checkpoints will be uploaded. When you chose the destination, it also says how. If a saved destination is unusable, it reports the problem instead of showing the privacy notice, unless checkpoints still upload to a dedicated checkpoint repository.