Record main's history as an ancestor of release (no file changes — must NOT be squashed)

[M3gA-Mind]

Read this before the diff

This PR changes no files. That is correct and intended. It will show ~188 commits and 0 files changed. Its entire purpose is to record main's history as an ancestor of release. There is nothing to review in a diff, because there is no diff — what needs reviewing is the merge itself, and how it lands.

It must land as a real merge commit. If it is squashed it accomplishes nothing at all — see How this must be merged.

What this is

release already contains every line of main's code. What it does not contain is main's history.

#5433 promoted main into release and was squashed on merge. A squash writes a single commit with a single parent, so the tree came across but none of main's 187 commits became ancestors of release. Git's view of the two branches is therefore unchanged from before that PR: the merge-base is still frozen at 2219d4207.

This merge fixes the history and touches nothing else.

$ git diff --stat upstream/release
                                        ← empty

$ git log -1 --pretty=%P
9fb45e01a701f2cb479b7243d2fe469d51b57ced 8deb5f2769c97ad059be2a6acae9f23c9c00dc3b
   ← release, v0.63.11                      ← main, #5427

Stated more strongly than "no meaningful changes": the merge's tree object is byte-identical to release's current tree.

$ [ "$(git rev-parse HEAD^{tree})" = "$(git rev-parse upstream/release^{tree})" ] && echo identical
identical

The code is already in release — evidence

Whole-tree. main and release differ in six files, all version-bearing, and nothing else:

$ git diff --stat upstream/release upstream/main
 Cargo.lock                    | 2 +-
 Cargo.toml                    | 2 +-
 app/package.json              | 2 +-
 app/src-tauri/Cargo.lock      | 4 ++--
 app/src-tauri/Cargo.toml      | 2 +-
 app/src-tauri/tauri.conf.json | 2 +-
 6 files changed, 7 insertions(+), 7 deletions(-)

Per-commit, at the tip. The four newest commits on main touch 47 files between them, and every one of those 47 is byte-identical in release:

main commit	files touched	identical in release
8deb5f276 fix(memory) — #5427	25	25
bb4493ce4 fix(voice) — #5428	2	2
d7819492c feat(mascot) — #5420	18	18
e29bfc66f feat(threads) — #5412	2	2

And the squash is visible directly. #5433 landed with exactly one parent:

$ git log -1 --pretty='%h parents=[%P]' 18db547ca
18db547ca parents=[2ba803a246f8af20e3278c8acb62f34be2b421f5]

One parent — release's previous tip. Main appears nowhere in it.

Why the counter says "187 behind"

GitHub's branch comparison is three-dot: it counts commits reachable from main but not from the merge-base, not from release's tip. With the merge-base frozen at 2219d4207 by successive squashes, every commit main has landed since then counts as "ahead", regardless of whether its content is sitting in release already. It is a statement about ancestry, and ancestry is exactly what the squashes failed to record.

So the 187 is not wrong — it is measuring the real problem. It just isn't measuring code.

What merging this fixes

• git rev-list --count release..main becomes 0 (it is 187 today). The "behind" counter clears.
• Main's SHAs become reachable from release. release-staging.yml takes a commit_sha input that must be reachable from the release branch; today a main SHA is not, so staging cannot be pinned to one.
• The next promote fast-forwards instead of re-deriving conflicts from a stale merge-base. The last two promotes hand-resolved 14 and then 6 conflicts, none of which were real divergence — they were the kernelization's own file moves, re-derived as add/add and rename/delete pairs because git could not see that release already held main's tree.

The version files

Six conflicts, all version-bearing, all resolved by keeping release's side at v0.63.11 (main is on 0.63.6 — a release must never go backwards).

That resolution is the only way this merge could have changed a file, and it must not. Each of the six was verified identical to release's copy afterwards, rather than trusting the merge strategy.

How this must be merged

This repository is allow_merge_commit: false — squash-only.

Squashing this PR reproduces #5433 exactly: a single-parent commit, no ancestry recorded, the merge-base still 2219d4207, the counter still 187, staging still unable to pin a main SHA, and the next promote fighting the same conflicts with everything merged since added to them. The PR would appear to succeed and change nothing whatsoever — and because its diff is empty, there would be no symptom to notice.

There is no resolution or rebase that works around this. A squash cannot record a second parent; that is what a squash is.

So this needs one of two things from a maintainer, and it cannot land correctly without one:

1. Enable merge commits for this repository (or for release specifically) long enough for this to land as a real merge — this is the option that also fixes every future promote; or
2. An admin pushes the merge directly, bypassing the squash-only setting:

   git fetch origin release chore/record-main-ancestry-in-release
   git checkout release
   git merge --no-ff chore/record-main-ancestry-in-release
   git push origin release
   

Option 1 is worth taking on its own merits. Squash-only on a promote branch is what created this situation, and it will keep creating it: the previous two promotes cost hand-resolutions of 14 and 6 conflicts, and this PR exists solely to repair what the second one could not record.

Verification

• git diff --stat upstream/release → empty; tree object identical to release's
• git log -1 --pretty=%P → two parents, release then main
• git merge-base --is-ancestor upstream/main HEAD → yes (it is no for release today)
• git rev-list --count HEAD..upstream/main → 0
• git status --porcelain → clean, no untracked or extra path
• Conflicts were exactly the six version files; each verified identical to release's copy after resolution
• No build was run locally.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 993c3509-41b2-4e4f-b3b3-21a854863053

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}