v0.2.1 — finish the no-op-commit fix

Patch release for a real-world bug that slipped through v0.2.0.

What broke in v0.2.0

v0.2.0 gated the commit path on len(pendingRepoWrites) > 0, which caught most no-op cases. It missed one: when a three-way merge resolves to content identical to what's already on disk, pendingRepoWrites is non-empty (holds the merged blob) but the filesystem doesn't actually change. The gate then went ahead and rewrote README + manifest — both carry time.Now() — which did change the filesystem, so HasChanges returned true and we committed anyway.

Symptom: git log filling with +0 ~0 -0 commits, and two machines pushing those phantoms into predictable non-fast-forward divergence. Any error: non-fast-forward update: refs/heads/master after upgrading to v0.2.0 is this.

What v0.2.1 does

Reorder the commit path: write pendingRepoWrites first, then check HasChanges, and only touch README + manifest when there's a real diff to commit. No diff = no commit.

Upgrade

curl -fsSL https://raw.githubusercontent.com/colinc86/ccsync/main/scripts/install.sh | bash

Or from within the v0.2.0 TUI: Settings → check for updates → enter.

If your machine is currently stuck with orphan no-op commits

v0.2.1's first run through SyncToRemote discards them automatically, but if you want to tidy up manually first:

cd ~/.ccsync/repo
git fetch origin
git reset --hard origin/master

Then run ccsync sync. Should come back clean.