Some FaceKom clones have a narrowed remote.origin.fetch refspec. In those clones git fetch origin devel updates only FETCH_HEAD — it does not update refs/remotes/origin/devel — yet it prints a success line and exits 0. A following git merge origin/devel then merges whatever stale tree that ref last pointed at: conflict-free, no warning, wrong content.
This has already almost shipped a release without its headline feature
During FKITDEV-9194 (Generali release 1.9.11.19 prep, 2026-08-08) the first
vuer_cssmerge used devel @7d4f9956c8(2026-07-28) while live devel was3ace8872c3(2026-08-07). Six commits were silently dropped, including:
6bdf66d16 fix: [fkitdev-8887] recover WebRTC audio after iOS Safari interruption (#3066)That commit is ASSGRALI-63 — the headline changelog item of the very release being prepared. Caught only by an explicit ref-vs-remote assertion.
The mechanism
git -C /Users/levander/coding/facekom/vuer_css config --get remote.origin.fetch
# +refs/heads/customization/raiffeisen:refs/remotes/origin/customization/raiffeisenThe configured refspec covers one branch. When you run git fetch origin devel — a bare branch name with no destination — git fetches the objects and writes FETCH_HEAD, but there is no configured mapping telling it to also move refs/remotes/origin/devel, so it leaves that ref exactly where it was (possibly months old, possibly absent).
Nothing about the output distinguishes this from a normal fetch. Exit code is 0.
Why the merge doesn't save you
git merge origin/develresolvesorigin/develfrom the local ref, not from the remote. Merging an older devel into a partner branch that already contains newer devel commits is a perfectly valid, conflict-free merge. There is no signal at all — no conflict, no warning, no “already up to date”. The diff just quietly lacks the newest commits.
The fix — always use an explicit destination refspec
# fetch WITH a destination, so the remote-tracking ref actually moves
git fetch origin '+refs/heads/devel:refs/remotes/origin/devel'The assertion — always verify before merging
git rev-parse origin/devel
git ls-remote origin refs/heads/develThese two must be equal. If they differ, your origin/devel is stale and any merge from it is wrong. Run this every time in a narrowed clone — the explicit refspec and the assertion are cheap; the failure mode is invisible.
Which clones are affected
| Repo | remote.origin.fetch | Affected? |
|---|---|---|
vuer_css | +refs/heads/customization/raiffeisen:… (one branch) | YES |
vuer_oss | +refs/heads/*:refs/remotes/origin/* (full) | No |
esign_css has historically shown the same narrowing. Do not assume — check git config --get remote.origin.fetch per clone; narrowing is a property of how the clone was made, not of the repo.
For Agents
Before any
merge,rebase, fast-forward, tag or push that referencesorigin/<branch>in a FaceKom clone:
git config --get remote.origin.fetch— is it+refs/heads/*?- If not, fetch with an explicit destination:
git fetch origin '+refs/heads/<b>:refs/remotes/origin/<b>'- Assert
git rev-parse origin/<b>==git ls-remote origin refs/heads/<b>.A related consequence of the same narrowing:
git push --force-with-leaseis rejected with “stale info” and needs the explicit--force-with-lease=<branch>:<oldsha>form (seen in FKITDEV-9022).
Related
- FKITDEV-9194 — the Generali round where this was caught one step before it shipped.
- devel-update-and-release-flow — where this check sits in the wider devel-update → release procedure (Phase 0.3 and Phase 1.3).
- FKITDEV-8887 · ASSGRALI-63 — the fix that was almost dropped.
- FKITDEV-9022 — the
--force-with-lease“stale info” variant of the same root cause. - vuer_css — clone-level gotchas for this repo.
- release-process · vuer-release-cut-recipe — where a stale ref would also do damage (tagging the wrong tree).