fix(zaparoo): stable build applies full fork diff incl input.cpp/scheduler.cpp

The stable build excluded input.cpp/scheduler.cpp and re-applied a hardcoded
hook set via apply_stable_hooks.py. That script drifted behind PRs #11/#12,
which added input.cpp edits (the launcher_input_detect.inc include defining
input_export_launcher_metadata, plus keyboard-grab/bridge hooks) it never
learned — so stable builds failed to link (undefined reference to
input_export_launcher_metadata) and would have shipped degraded launcher input.

git apply -3 applies the full fork diff for these files cleanly against the
stable release base (upstream has no drift there), same as every other
fork-touched upstream file. Drop the exclusions and the bespoke script so the
fork diff is the single source of truth.

Fixes the failing stable Push Release build.

Author: wizzomafizzo

.github/apply_stable_hooks.py

@@ -62,10 +62,9 @@ This fork auto-syncs upstream daily and publishes **two channels from two branch
    build layers the fork diff `upstream/master..<branch>` onto an upstream base, so that diff
    must stay **fork-only** — keep both branches upstream-synced.
 3. **Promote to the distribution only when explicitly asked:**
-   `git checkout stable && git merge master && git push origin stable`. If the promoted feature
-   adds *new* hooks to `input.cpp` or `scheduler.cpp`, also update
-   `.github/apply_stable_hooks.py` on `stable` (stable's hooks in those two files come from that
-   script, not the diff).
+   `git checkout stable && git merge master && git push origin stable`. The stable build applies
+   the full fork diff with `git apply -3`, so `input.cpp` / `scheduler.cpp` hooks promote like any
+   other fork-touched file — no extra step.
 
 Full details: `support/zaparoo/RELEASE.md`.
 

AGENTS.md

@@ -80,25 +80,18 @@ git worktree add --detach "${TMP_WORKTREE}" "${STABLE_COMMIT}" >/dev/null
 
 # Apply the cumulative fork-only diff (relative to upstream master) so revert
 # pairs and other intra-fork conflicts cancel out — replaying commit-by-commit
-# would re-expose them. -3 falls back to a 3-way merge when stable's content
-# for a shared file has drifted from upstream master. MiSTer.ini is excluded:
-# the fork's only change is an uncomment of a default-valued line, and stable's
-# example ini drifts often enough to cause spurious conflicts.
+# would re-expose them. -3 falls back to a 3-way merge when stable's content for
+# a shared file (including input.cpp / scheduler.cpp) has drifted from upstream
+# master — the same mechanism used for every fork-touched upstream file, so the
+# fork diff stays the single source of truth. MiSTer.ini is excluded: the fork's
+# only change is an uncomment of a default-valued line, and stable's example ini
+# drifts often enough to cause spurious conflicts.
 FORK_DIFF=$(git diff --binary "${UPSTREAM_REF}..${FORK_HEAD}" -- . \
-    ':(exclude)MiSTer.ini' \
-    ':(exclude)input.cpp' \
-    ':(exclude)scheduler.cpp')
+    ':(exclude)MiSTer.ini')
 if [ -n "${FORK_DIFF}" ]; then
     printf '%s\n' "${FORK_DIFF}" | git -C "${TMP_WORKTREE}" apply -3 --index
 fi
 
-# These hook files drift across stable/master often. Apply the small Zaparoo
-# hook additions by function scope instead of using upstream-master patch context.
-if [ -n "$(git diff --name-only "${UPSTREAM_REF}..${FORK_HEAD}" -- input.cpp scheduler.cpp)" ]; then
-    .github/apply_stable_hooks.py "${TMP_WORKTREE}"
-    git -C "${TMP_WORKTREE}" add input.cpp scheduler.cpp
-fi
-
 "${TMP_WORKTREE}/docker-build.sh" "$@"
 
 mkdir -p "${OUTPUT_DIR}"

stable-build.sh

@@ -21,8 +21,8 @@ release channels, so upstream syncing and fork-feature promotion are decoupled.
 - **Unstable** (`.github/build_unstable_release.sh` → `unstable-build.sh`): upstream `master`
   HEAD base + `git diff upstream/master..master`.
 - **Stable** (`.github/build_release.sh` → `stable-build.sh`): upstream's latest tagged
-  release (`releases/MiSTer_*`) base + `git diff upstream/master..stable`, with the
-  `input.cpp` / `scheduler.cpp` hooks re-applied by `.github/apply_stable_hooks.py`.
+  release (`releases/MiSTer_*`) base + `git diff upstream/master..stable`, applied with
+  `git apply -3` (3-way, tolerates upstream drift) — `MiSTer.ini` is the only exclusion.
 
 Each channel is built from a checkout of its **own branch**, so its content, build scripts,
 and hook list all come from that branch.
@@ -41,16 +41,10 @@ When a beta feature on `master` is ready to ship to everyone:
 ```sh
 git checkout stable
 git merge master            # or cherry-pick specific commits for a partial promotion
-# If the promoted feature adds NEW hooks to input.cpp or scheduler.cpp, also update
-# .github/apply_stable_hooks.py on stable to include them (see caveat below).
 git push origin stable      # triggers a fresh MiSTer_Zaparoo_YYYYMMDD stable release
 ```
 
-### Caveat: input.cpp / scheduler.cpp hooks
-
-The stable build excludes `input.cpp` and `scheduler.cpp` from the fork diff and instead
-re-applies a **hardcoded** set of hooks via `.github/apply_stable_hooks.py`. So stable's
-hooks in those two files are governed by that script, not by merging the diff. Promoting a
-feature that adds new hooks to either file requires editing `apply_stable_hooks.py` on the
-`stable` branch as well. Features that only touch new `support/zaparoo/*` files (or other
-upstream files) are handled by the diff alone — no script change needed.
+The stable build applies the **full** fork diff with `git apply -3`, so hooks in `input.cpp`
+/ `scheduler.cpp` promote exactly like any other fork-touched file — there is no separate
+hook list to maintain. If upstream ever drifts those files enough that the 3-way apply
+conflicts, the stable build fails loudly (rather than silently shipping a stale hook set).