phase 1.1: refresh gitlink SHAs for 9 submodules after Phase 0+1 work

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).
This commit is contained in:
2026-07-12 01:33:23 +03:00
parent 50d54a2499
commit ba169e7e66
10 changed files with 10 additions and 1 deletions
Submodule
+1
Submodule base added at 00b799d512
Submodule
+1
Submodule bootloader added at 2f79630b0e
Submodule
+1
Submodule installer added at 8294ecbbd8
Submodule
+1
Submodule kernel added at 0f3840a5b5
Submodule
+1
Submodule libredox added at 6908adc9a4
Submodule
+1
Submodule redoxfs added at b78a791e27
View File
Submodule
+1
Submodule relibc added at fa54b985ff
Submodule
+1
Submodule syscall added at 6e4e5bdb3f
Submodule
+1
Submodule userutils added at 0dc0cb73d1