# Landing core PR #268: `--rebase` rewrote the sha, so the ff assertion FAILED

Measured 2026-09-24, doyle, HFENDULEAM. This falsifies the how-to-apply half of my own
`land-267-merge-commit-deviation.md` record and the memory rule built on it.

## What I did

PR #268 (IR-135 amendment, docs-only) was a single commit whose parent was already current main:

- head `488ee001309c8b9562511ef28cf8980554c495ed`, parent `437562d9` == `origin/main` tip
- CI green: changes + traceability SUCCESS, unit/lint/docs-drift SKIPPED (thin docs lane), run `36025710031`
- landed with `gh pr merge 268 --repo BigscreenVR/spt-bs-core --rebase --delete-branch`

## What came out

    mergeCommit.oid  447fc9eba2c30bbe60f28cf797e8047cf83477ea
    headRefOid       488ee001309c8b9562511ef28cf8980554c495ed   <- NOT equal

    488ee001 tree   206710e827c5ec7bbab7404ec9b25d970d9a66cb
    447fc9eb tree   206710e827c5ec7bbab7404ec9b25d970d9a66cb   <- identical
    447fc9eb parent 437562d9d689271e925e0cf8a4c40b7907c12ad5   <- single parent, no merge commit

    488ee001 author 09:11:53 -0700  committer 09:11:53 -0700
    447fc9eb author 09:11:53 -0700  committer 09:14:54 -0700   <- committer date = merge time

GitHub re-committed the change even though the head was already a direct descendant of the base.
Author identity and date survive; the committer date is stamped at merge time, which is enough to
change the sha. **`--rebase` does not give sha identity.** The verb I prescribed after #267 is the
wrong verb, and it was prescribed from reasoning ("rebasing a commit onto its own parent rewrites
nothing"), never from a measurement.

The assertion itself did its job: it is the thing that caught this, exactly as intended. The failure
is in the verb it was guarding, not in the guard.

## Content risk on this landing: zero, measured

Tree identical, one parent, tip advanced `437562d9 -> 447fc9eb`. No untested content reached main;
what ADR-0050 protects is satisfied. As on #267, I did NOT force-push main to repair a cosmetic sha
while other agents are mid-lane against it. Recorded, not rewritten.

## The open question — sha identity IS achievable here

Three sibling lanes landed on this same repo, this same week, with `mergeCommit.oid == headRefOid`:

    #266  07d04ba5b6c489ae1a47e8eb51b854f3852224fa
    #264  b96b88d26893c9cb2a890e8a1eb176421d05ab6a
    #260  957d556d84e98ba2fcb3c72e01bcd20bc347592b

All three merged through the API by the same actor (`SaberMage`, per the issue timeline), all three
with the committer preserved as the original author. #260 even carries a committer date that differs
from its author date by 44 minutes and STILL landed at its own sha — so that skew was already in the
commit before landing, not stamped by the merge. The precondition on #268 was the same (head parent
== base tip) and the outcome differed, so **the verb differed.** I have no landing record for those
three and I am not going to invent a mechanism for them: asked hertz, who ran those CI lanes, for the
verb he actually typed. Until he answers, the mechanism of identity is UNMEASURED.

Leading hypothesis, explicitly untested: a direct `git push origin <sha>:main` fast-forward, after
which GitHub auto-closes the PR as merged with `merge_commit_sha` == the pushed head. That is
consistent with every number above and with nothing yet proven.

## How to apply, today

1. Keep the assertion. `gh pr view <n> --json mergeCommit,headRefOid`, require equality, run it
   BEFORE calling a lane landed. It is the only thing that has caught either verb.
2. Do not trust `--rebase` to satisfy it, and do not trust `--merge` (which builds a two-parent
   merge commit outright, #267). Neither `gh pr merge` verb is known to preserve the sha.
3. When the assertion fails, measure the tree and the parent before deciding anything. Identical
   tree + single parent == no untested content on main, which is a deviation to record, not an
   incident to force-push.

Related: `.spt/preserved/331/land-267-merge-commit-deviation.md`.