Round 5/6 left the base fork unable to be force-pushed to origin.
After investigation in Phase 5.3, the actual cause was identified:
the gitea server's receive.shallowUpdate=true config (not the
ref name as previously thought).
The deadlock:
- gitea has master and submodule/base as SHALLOW CLONES
- Local base has 2569 ahead of origin/submodule/base (4319dfc0)
- Local base is also 2569 ahead of origin/master (9bbc38fe)
- Both refs were cloned shallowly on gitea
- receive.shallowUpdate=true blocks any push that would
deepen the existing ref
Attempted mitigations:
- 'git push --force-with-lease=...' → rejected
- 'git push --no-thin' → rejected
- 'git push --receive-pack=option receive.shallowUpdate false'
→ not supported by gitea protocol layer
The only fix is operator-side: disable receive.shallowUpdate on
the gitea repo. Per AGENTS.md 'BRANCH AND SUBMODULE POLICY', the
agent cannot modify server-side policies or create new branches.
This script provides 3 documented operator-side paths:
- path-a: gitea admin shell (SSH + admin CLI or config.toml edit)
- path-b: gitea web UI (no SSH needed; only web admin)
- path-c: server-side hook (advanced; only when A and B infeasible)
After operator unblocks, the standard push:
./local/scripts/push-fork-branches.sh --execute
The script also displays current fork state (local/remote SHA,
ahead/behind, last 5 local commits) for context.
Files in scope: local/scripts/unblock-base-push.sh
vasilito
57c6da39bd