An auto-push that swallows failures produces permanent desync

Symptom

The daily auto-commit-and-push stops reaching the remote one day. No log, no alert. It happened the first day auto-push was turned on.

Cause

Another session or another machine pushes one commit to the remote, and from then on every push is a non-fast-forward rejection. A script that swallows failures swallows that too.

Fix — the order matters

add → commit → pull --rebase origin main → push

★ pull --rebase must not come before commit. The file you just wrote leaves the working tree dirty and the rebase refuses with "unstaged changes."

A rebase left halted on a conflict blocks every following run, so add a fallback:

for st in rebase-merge rebase-apply; do
  [ -d ".git/$st" ] && git rebase --abort && break
done

The fallback's limit, honestly

Auto-resolving with -X theirs silently overwrites what someone hand-fixed on another machine. So giving up on that run is the right answer when there is a conflict. But this fallback protects the repo, not the work. The fact that a conflict happened is not recorded anywhere.

Verification

On days when several actors touch the same file, git log --oneline -3 after push to confirm your commit is actually there.

Suspected duplicate — don't compare drafts

The draft pasted into chat and what was actually pushed can differ (it gets rewritten to house style right before the push). Comparing drafts against each other yields a false "another session added more and pushed it." Judge from the real thing.

git log --format='%h|%s' origin/main -- '<path>'

One commit, and it's yours: no duplicate.

---

---