| name | git-deploy-poller-fetch-merge-refstore-split |
| description | A git-based deploy poller that `git fetch`es in one directory but `git merge`s in another silently no-ops — and rebuilds stale code forever — when the two directories don't share a ref store. Happens when one project's working dir is a standalone clone instead of a worktree of the shared bare repo the poller fetches into. |
| metadata | {"type":"reference"} |
Git deploy poller — fetch-here, merge-there ref-store split
Symptom
A cron/launchd auto-deploy poller logs the SAME commit being "deployed"
over and over, every interval, forever:
[BSupervisor] Deploying aa9a7b4...
Already up to date.
... (rebuild) ...
[BSupervisor] Done
[BSupervisor] Deploying aa9a7b4... ← again, ~4 min later
The container is rebuilt every cycle but from stale code — the merge
that should advance the working tree reports Already up to date even
though the working tree HEAD is demonstrably behind the remote.
Root cause
The poller is typically written like:
BARE=~/Works/$name/.bare
WORK=~/Works/$name/main
git -C "$BARE" fetch origin main
LOCAL=$(git -C "$WORK" rev-parse HEAD)
REMOTE=$(git -C "$BARE" rev-parse origin/main)
[ "$LOCAL" != "$REMOTE" ] && git -C "$WORK" merge origin/main --ff-only
This is correct only if $WORK is a linked worktree of $BARE — then
they share one object DB and one set of refs, so origin/main resolves to
the same SHA in both.
If $WORK is instead a standalone clone (its own .git, its own
origin remote), it has its own refs/remotes/origin/main. The poller
never fetches that clone, so its origin/main stays frozen at whatever
it was last fetched. Then:
REMOTE (from $BARE) = new SHA → LOCAL != REMOTE is truegit -C "$WORK" merge origin/main uses $WORK's stale origin/main
→ Already up to date → HEAD never advances- next cycle: same thing → infinite stale rebuild loop
The build context (docker-compose up --build) is $WORK, so every
rebuild ships the OLD code while the .deployed state file gets bumped to
the new SHA — masking the failure.
How to detect
git -C "$WORK" worktree list
git -C "$WORK" rev-parse origin/main
git -C "$WORK" remote -v
If $WORK's origin/main ≠ $BARE's origin/main, you've found it.
Fix
Immediate (unblock one project): fetch in the clone itself, then merge:
git -C "$WORK" fetch origin main
git -C "$WORK" merge origin/main --ff-only
docker-compose -p <proj> -f deploy/docker-compose.yml up -d --build --force-recreate
Pause the poller (launchctl unload …) while doing this so it doesn't
race the manual docker-compose; re-enable after.
Root cause: make every project's working dir a real worktree of the
shared bare repo, OR make the poller git fetch in $WORK (not just
$BARE). One project being a standalone clone while the rest are worktrees
is the silent inconsistency — audit all of them.
Generalizes to
Any "fetch refs in location A, act on them in location B" automation where
A and B are assumed to share a ref store but one drifted into being a
separate repo. The fix is always: fetch where you merge, or guarantee a
shared ref store.
