From 831d3db8b12bdea0f63fabb01f96faccfd524c4d Mon Sep 17 00:00:00 2001 From: vasilito Date: Sun, 12 Jul 2026 09:31:08 +0300 Subject: [PATCH] phase 4.1: add fork-push-status doc (Phase 4.0 push results + base deadlock) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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= 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 --- .../2026-07-12-Round-5-phase-4.1.md | 77 +++++++++++++++++++ 1 file changed, 77 insertions(+) create mode 100644 local/docs/fork-push-status/2026-07-12-Round-5-phase-4.1.md diff --git a/local/docs/fork-push-status/2026-07-12-Round-5-phase-4.1.md b/local/docs/fork-push-status/2026-07-12-Round-5-phase-4.1.md new file mode 100644 index 0000000000..86dce1c6e9 --- /dev/null +++ b/local/docs/fork-push-status/2026-07-12-Round-5-phase-4.1.md @@ -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=` 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. +