Skip to main content
If checkpoint history should live somewhere other than the source repository, configure a checkpoint remote.

​
Create a checkpoint repository

Create a separate, empty repository for checkpoint data, then run this from your project:
Replace owner/repo with the repository you created for checkpoint data. The value uses the format provider:owner/repo. Currently, github is the supported provider.

​
Settings

This writes the checkpoint remote to .entire/settings.json:
After this is configured, your code continues to live in the main repository, while checkpoint data is pushed to the separate repository. Commit and push .entire/settings.json when the checkpoint remote should apply to the whole project. Entire.io uses that setting to locate checkpoint data.

​
When to use another repo

This is useful when:
  • checkpoint data should follow a different sharing boundary than source code
  • your team keeps development metadata outside the source repository
  • you want to keep the source repository focused on source code

​
Push behavior

When you push code, Entire pushes the configured checkpoint data to the checkpoint repository separately. It uses the same protocol as your Git remote, such as SSH or HTTPS. If the checkpoint repository cannot be reached, your main Git push still succeeds. Entire keeps the checkpoint data locally and warns that it could not sync.

​
Keep checkpoints under the same owner

Use a checkpoint repository with the same owner or organization as your code repository:
  • Same owner — checkpoints push normally. If your code is at github.com/acme/app, a checkpoint repo like github:acme/app-checkpoints works because both are owned by acme.
  • Different owner — Entire won’t push checkpoint data to that repository.
The different-owner case is an intentional design to protect forks, keeping fork contributors from needing write access to the upstream project’s checkpoint repository.