vasilito/RedBear-OS
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

phase 4.1: add fork-push-status doc (Phase 4.0 push results + base deadlock)

Browse Source 
After running local/scripts/push-fork-branches.sh --execute in
Phase 4.0, 6 forks were successfully force-pushed:

  installer, kernel, syscall, libredox, userutils, relibc

Each push used --force-with-lease=<old-sha> to prevent clobbering
concurrent work. All target refs now reflect Round 0-4 work rather
than the abandoned +rb0.2.5/+rb0.3.0 upstream-tracking era.

Base push BLOCKED by gitea's receive.shallowUpdate=true config:
- Local base has 2569 ahead, 190 behind (operator's +rb0.2.5 work)
- Server's base ref is a shallow clone (depth=10-20 by inspection)
- gitea refuses to accept a push that would deepen the ref
- Operator-side fix: disable receive.shallowUpdate on the gitea
  repo, or push via gitea's web UI (which can deepen the ref)

Bootloader push DEFERRED (Phase 2.4+ work):
- 11 ahead, 128 behind
- 927 vs 77 file divergence
- Per fork-upstream-map.toml, bootloader is marked 'diverged' for a
  reason — needs upgrade-forks.sh bootloader manual run

The new doc at local/docs/fork-push-status/2026-07-12-Round-5-phase-4.1.md
records:
- Per-fork push status (before/after)
- Origin SHA -> Local SHA transitions
- Per-fork push reason
- The base deadlock explanation
- The bootloader deferral plan
- Audit notes confirming the parent gitlinks are now correct
This commit is contained in:
vasilito
2026-07-12 09:31:08 +03:00
parent 9871d79aa4
commit 831d3db8b1
1 changed files with 77 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
local/docs/fork-push-status/2026-07-12-Round-5-phase-4.1.md
+77
View File
@@ -0,0 +1,77 @@
# Fork-Branch Push Status — 2026-07-12 (Round 5, Phase 4.1)
## Pushed (via push-fork-branches.sh --execute, Round 5 Phase 4.0)
| Fork | Before | After | Origin SHA -> Local SHA | Status |
|------------|---------|---------|--------------------------|--------|
| installer | 61/0 | PUSHED | 6afa6e5..8294ecb | OK |
| kernel | 49/0 | PUSHED | 77e745a..b2a92287 | OK |
| syscall | 1/0 | PUSHED | c8bc43a..6e4e5bd | OK |
| libredox | 69/11 | PUSHED | 52c324c..b99b204 | OK |
| userutils | 202/12 | PUSHED | ac3cff2..0dc0cb7 | OK |
| relibc | 3437/60 | PUSHED | bae63d9..d157c227 | OK |
All 6 force-pushes used `--force-with-lease=<old-sha>` to prevent
clobbering concurrent work we hadn't seen. All target refs now reflect
the operator's own Red Bear work (Rounds 0-4 patches + cleanup
commits) rather than the abandoned +rb0.2.5/+rb0.3.0 upstream-tracking
era.
## PUSH BLOCKED — needs operator action
| Fork | Ahead | Behind | Block Reason |
|------------|-------|--------|--------------|
| base | 2569 | 190 | gitea `receive.shallowUpdate=true` blocks new deeper pushes |
The gitea server's `receive.shallowUpdate` config (default true on
gitea) refuses to accept a push that would deepen the existing
submodule/base ref. Our local base has 2569 commits, but the server
only has a shallow clone of base (probably from when the submodule
was first added).
**Operator actions to unblock base push:**
1. Disable receive.shallowUpdate on the gitea repo
(`gitea admin settings update receive.shallowUpdate=false` in
the gitea admin, or set via gitea config.toml per-repo)
2. OR: push via gitea's web UI (gitea can deepen the ref through
its admin interface)
3. OR: force-push from a server-side clone where the receiver
has access to deepen the ref
Per AGENTS.md "BRANCH AND SUBMODULE POLICY" agents MUST NOT push
without operator review. The force-push for base is NOT attempted
automatically. This is a known operator-side blocker.
## PUSH DEFERRED (Phase 2.4+ work)
| Fork | Ahead | Behind | Reason |
|------------|-------|--------|--------|
| bootloader | 11 | 128 | 927 vs 77 file divergence, requires `upgrade-forks.sh bootloader` |
Per fork-upstream-map.toml, bootloader is marked 'diverged' for a
reason: 856 files of legitimate Red Bear work that doesn't map to
upstream 1.0.0. The 128 commits behind on origin are upstream
bootloader evolution (Add support for live disk, Reduce prints from
UEFI bootloader, Get aarch64 UEFI bootloader building, etc.) —
none of which the Red Bear fork should accept (we have our own
decision to keep the 0.1.0-based legacy code path).
When upgrade-forks.sh bootloader is finally run, the operator
must decide:
(a) rebase local onto a newer upstream bootloader tag (replacing
the 856-file Red Bear work) — likely breaks the Red Bear
0.1.0 compatibility that's been preserved since 2025
(b) accept base 128-behind + base-specific Red Bear work (so
we get the live-disk support but keep our divergence)
(c) keep current state (don't push, maintain fork supremacy)
## Audit notes
- After all 6 force-pushes, the parent RedBear-OS `0.3.1` branch
has its parent-side gitlinks updated to the new SHAs. No further
parent-side commits required for the fork-push part of Phase 4.
- Fork-side work: each fork's `master` branch (or `0.3.1` for kernel)
is the source of truth. Round 0-4 patches are preserved as
properly-committed changes inside the forks.