You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit dfce7ef
Browse filesBrowse the repository at this point in the historyBrowse files
authored
🐛 fix(automerge): an approval carries over a base merge that only moved the PR's hunks (#17374)
The workflow-path fence (and the operator-decision carry, the review-head
binding and the base-preparation proof, which share the same check) carried
an approval across the hive's own merge of the base branch only when every
file in the PR's three-dot diff kept the same resulting blob. When main had
also edited a file the PR changes, away from the PR's lines, the blob
changed even though every hunk was byte-for-byte the same at shifted line
numbers, so the fence re-armed and the PR sat at stage/085 until someone
approved the identical change again (projectbluefin/utah-packages#924:
hanthor approved 1417928, the hive merged main in as 11e168e, and main had
edited docs/skills/upstream-version-bumps.md 15 lines above the PR's hunk).
sameChangedFiles now accepts a different blob for a plain modification
outside any .github/ directory when GitHub returned a patch for both sides
and the patches are equal once each hunk header's two start lines are
dropped (context, added and removed lines, hunk lengths and section
headings must all match). Workflow and action files still have to read
exactly as approved, and a merge that changed the PR's hunks or their
context still needs a new approval.
Claude-Session: https://claude.ai/code/session_01BQYnPGFJx81c8JXR3o1sg1
Signed-off-by: Danathar <Danathar@users.noreply.github.com>
Co-authored-by: Danathar <Danathar@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: hivecommons-hive[bot] <280983584+hivecommons-hive[bot]@users.noreply.github.com>
- An approval or recorded decision now carries over the hive's own merge of the base branch when the base also edited a file the PR changes, as long as the edit is away from the PR's hunks: every hunk is still byte-for-byte what was approved and only its line numbers moved, so the workflow-path fence no longer re-arms and the PR no longer parks at `stage/085-needs-decision` waiting for a fresh approval of the same change (projectbluefin/utah-packages#924). Files under `.github/` still have to read exactly as approved, and a base merge that touched the PR's own hunks or their context lines still needs a new approval.
0 commit comments