v0.4.1 — A no-change Push makes no storage requests
Push no longer asks storage about blobs this machine already confirmed. Every Push used to make one existence request per tracked blob, changed or not — on Google Drive a files.list query each, behind a token refresh; on S3 a signed HEAD each. Auto Push runs on focus changes, so a project where nothing moved still paid a network round trip per file on every sync.
The proof was already on disk: Library/remote-*.json records every blob this machine uploaded, downloaded, or saw storage confirm. Push loaded that record, wrote to it — and never read it. It now seeds its "present on remote" set from the record and asks only about blobs it has no proof for.
What this means in practice
- A Push and a Pull where nothing changed make zero storage requests. The whole run is local file stats against the (mtime, size) hash cache.
- A fresh clone's first Push still checks everything once, earns the confirmations, and only then goes quiet. The record is per machine and per bucket.
- Changed and new content is checked exactly as before — including the dedup that skips uploading bytes some other path already pushed.
The trade-off, and why it is safe
A blob deleted from the bucket after this machine confirmed it now hides behind the stale record, where the old Push noticed by accident. That case was always Verify's job — Refresh in the window, UniLfsCli.Verify in CI: it asks storage for real, retracts every confirmation storage denies, and the next Push then checks and re-uploads. That loop is pinned by an end-to-end test against a stand-in storage server, alongside tests that a no-change Push makes no requests and that a clone without proof still asks before skipping an upload.
Deleting Library/remote-*.json is also always safe: every confirmation is forgotten, the next Push checks everything once and earns them back.
Upgrading from 0.4.0
Nothing to do. No file formats changed; the confirmation record was already being written by 0.3.x and 0.4.0, so existing machines benefit immediately.