B-NNS4-backup-off-machine-remote-with-full-history
Not scheduled. Related: M-PZGL (retention and pruning), T-A97O-backup-prune-operation (the prune).
- A remote git repo holds the full snapshot history. The local store stays shallow, at the retention window.
- The app pushes after each snapshot, or on a schedule.
Rule once remotes exist
Section titled “Rule once remotes exist”Prune never cuts deeper than the last snapshot the remote has.
- Git records that snapshot in the remote-tracking ref (
refs/remotes/<remote>/main) after a successful push. No extra bookkeeping is needed. - Prune cutoff = the older of the retention cutoff and the last pushed snapshot.
- Pushing from a shallow store works. Every unpushed snapshot and its parent are present locally.
Edge cases
Section titled “Edge cases”| Case | Behavior |
|---|---|
| Remote unreachable for weeks | Prune pauses at the last pushed snapshot and the store grows. Status shows “N snapshots not pushed, pruning paused”. |
| New or replaced remote | Cannot be filled from a shallow store. It starts at the store’s shallow boundary (see Migration). |
| History deleted or rewritten on the remote | Fetch before prune. Trust only what the remote reports. |
| New machine | Clone shallow with --shallow-since. This becomes a restore path. |
Migration
Section titled “Migration”Decided: T-A97O-backup-prune-operation ships now with no remote awareness. It gets no “floor” parameter. That was considered and declined.
Stores already pruned when remote support lands need a one-time migration. Their oldest history is gone, so the first push cannot give the remote full history. The migration:
- Seeds the remote from the local store’s shallow boundary. Either the remote accepts a
shallow push (for example
receive.shallowUpdate), or the boundary is re-rooted. - Records that the remote starts at that boundary.
- Applies the prune rule above from then on.
This is an accepted cost, not a risk to avoid now.
Open questions
Section titled “Open questions”- Which remote kinds to support first (a git host, a bare repo on a NAS, cloud storage).
- Push after every snapshot, or on a schedule.
- Auth and credential storage for the remote.