Feature request: preserve PR approvals when a stacked PR’s diff is byte-identical after restack

[nateberggren]

🏷️ Discussion Type

Product Feedback

💬 Feature/Topic Area

Other

Body

Today, when working with stacked pull requests (for example via the ‎gh stack CLI extension), any restack or rebase that changes the head SHA of a PR will cause existing approvals to be dismissed if branch protection is configured to “Dismiss stale pull request approvals when new commits are pushed.”

This is correct and desirable when the underlying changes actually differ, but it can be painful in stacked workflows where an upper PR’s effective diff against the base branch hasn’t changed at all; only its ancestry and commit IDs changed because a lower branch was edited and the stack was restacked.

Request

Introduce an optional mechanism for preserving approvals on a pull request when a new head commit is pushed and the resulting patch is byte‑identical to the previously‑approved state. Concretely:

• When a new commit becomes the PR head, compare the diff against the base branch to the previously approved diff.

• If the patch is identical (e.g., via a stable patch‑ID / diff‑hash comparison), allow branch protection to treat the approval as still valid, even though the SHA changed.

• This could be:

• A new repository/branch‑protection setting (for example: “Preserve approvals when content is unchanged across rebases”), or

• Behavior that applies specifically to stacks and/or to “restack” operations initiated by ‎gh stack.

Motivation

In stacked workflows:

• It’s common to update a lower‑level PR, restack with ‎gh stack sync or ‎gh stack rebase, and thereby rewrite the SHAs of upper PRs.

• Those upper PRs often end up with exactly the same file‑level changes they had before, relative to the trunk/main branch.

• However, any approval on those upper PRs is invalidated because their head SHAs changed, even though the reviewer has already approved the exact same content.

For teams with stricter branch‑protection and compliance requirements, this creates a tension:

• We want to keep “dismiss stale approvals on new commits” enabled for real content changes.

• But we also want stacked‑PR tooling to be first‑class, without forcing reviewers to repeatedly re‑approve byte‑identical changes after every restack.

Desired behavior (high level)

• If the new PR head results in different content (different patch vs base), keep current behavior: dismiss approvals.

• If the new PR head results in identical content (same patch vs base), optionally allow the system to:

• Keep existing approvals as valid, or

• Mark them as “carried forward across rebase” in the UI, while still satisfying branch protections.

This would make stacked PRs much more ergonomic in security‑sensitive setups, without weakening the guarantees that approvals reflect the actual code that will be merged.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[nateberggren]

FYI: I really like the gh stack functionality as it addresses real DX pain points. The loss of approval when making fixes lower in the stack that are isolated to that layer is the only remaining gap