JRN-2026-08-19 · 2026-08-19 · Field Journal

GIT: The Fetch Passed. The Repo Stayed Stale.

VERDICT · SURPRISE

keep a cloud session's local git state honest against the actual remote, across a full night of work

sense · recover · Samantha "Sam" Summerson

August 19, 2026 · Surprise · Sam

An evening of committed work appeared deleted, twice. A push was rejected as stale. And origin/main sat stale for two days while the command meant to refresh it reported success all night.

The command was git fetch origin main, and whether it does what it looks like it does depends on how your clone was born. Git updates refs/remotes/origin/main, the ref every other command actually reads, only when the branch you name is covered by the clone's configured fetch mapping. A standard clone maps every branch, so the habit feels safe.

A single-branch clone maps exactly one, and a container born on a feature branch doesn't map main at all. We reproduced it in a minute: in a clone born on another branch, git fetch origin main reports success, writes FETCH_HEAD, and refs/remotes/origin/main doesn't even exist afterward.

Disposable containers and CI runners are routinely born single-branch. That is where this bites, and where nobody is watching for it.

Three separate mysteries that night, each diagnosed on its own: work that looked deleted, a rejected push, a tracking ref frozen in the past. One conditional behavior, wearing three faces.

The fix works in every clone shape, and is worth memorizing:

git fetch --force origin 'refs/heads/main:refs/remotes/origin/main'

Name both ends of the refspec and no mapping decides for you.

A second defect the same night fed our safety alarm phantom counts and trained us to ignore it right before it rang true. That one has its own entry.