After Phase 0+1 work committed Cargo.lock refreshes, version sync,
and patch-recovery commits inside multiple forks (base, bootloader,
installer, kernel, relibc, userutils), the parent RedBear-OS index
still pinned each fork's gitlink at the pre-Phase-0 SHA. This
caused persistent 'M local/sources/<fork>' entries in 'git status'.
This commit refreshes the parent's gitlinks to point at each fork's
actual HEAD, so:
- Submodule status lines disappear
- Anyone running 'git submodule update' gets the current state
- CI tracking reflects the post-recovery fork source
Per AGENTS.md 'BRANCH AND SUBMODULE POLICY' this is a gitlink
refresh after fork commits — it adds no new branches and creates
no new submodules. The fork branches (submodule/<fork>, master,
0.3.1, etc.) are pre-existing.
Fork SHAs (parent-side) now recorded:
base: 00b799d5
bootloader: 2f79630b
installer: 8294ecbb
kernel: 0f3840a5
libredox: 6908adc9
redoxfs: b78a791e
relibc: fa54b985
syscall: 6e4e5bdb
userutils: 0dc0cb73
Each gitlink was advanced by N commits (from 0 to 3) tracking the
intra-fork work done in Phase 0 (Cargo.lock regen) and Phase 1.0A
(patch recovery).
vasilito
ba169e7e66