Security advisory merge ignores merge strategy and commit message

[BigLep]

🏷️ Discussion Type

Product Feedback

💬 Feature/Topic Area

Other

Discussion Details

I maintain filecoin-project/filecoin-pin and recently published a security advisory (GHSA-m5ph-mmg5-6w5h) using the private fork workflow. When I used Merge pull request(s) in the advisory UI to land the fix on the public default branch, the behavior did not match what our repository settings and release tooling expect. I am filing this to document the gap and suggest two targeted improvements.

What I observed

1. The advisory merge flow always creates a merge commit, even when the repository has allow_merge_commit: false and only allows squash or rebase merges. Our repo is configured squash + rebase only; the advisory flow still produced a merge commit on the default branch.

• Note: originally the UI wouldn't let me merge and I had no indication for why. I got around this by adding me as a bypass for the ruleset, which then meant it was able to do a standard merge commit (without me realizing that was what was going to happen).

3. The merge commit message is fixed to the standard "Merge pull request #N from owner/repo-ghsa-...:branch" format with no way to customize it. The underlying commits in the private fork (with conventional feat: / fix: / docs: messages) are not reflected in that merge commit message.

Why it matters

Many modern repositories disable merge commits and rely on squash or rebase to keep a linear, conventional-commit-friendly history. Release automation such as release-please, semantic-release, and similar tools often walk history with git log --first-parent. When the only first-parent commit is a generic merge message, the underlying conventional commit metadata is invisible to those tools.

In our case, a docs: change merged via the advisory flow did not appear in the open release-please CHANGELOG PR. We only noticed after publish when reconciling the release.

Asks

1. Honor repository merge settings in the advisory Merge pull request(s) flow: respect allow_merge_commit, allow_squash_merge, and allow_rebase_merge the same way the normal PR merge UI does (defaulting to the repo's preferred strategy when merge commits are disabled).

2. Allow merge commit message customization, or at minimum include the source PR's commit messages in the resulting default-branch commit so --first-parent release tooling can see conventional-commit metadata. Even when a merge commit is unavoidable, a customizable message (or squash-with-retained message) would prevent silent CHANGELOG omissions.

My understanding of workarounds people use today

• Open a normal public PR for the fix before publishing the advisory, instead of using Merge pull request(s) in the advisory UI.
• After publish, add a follow-up empty conventional commit on the default branch to re-surface the change for release tooling (what we did).
• For release-please specifically, use a BEGIN_COMMIT_OVERRIDE block in a follow-up PR body to manually inject CHANGELOG entries.

Prior art

• Security Advisories Feature Requests & Improvements: @gtjoseph (Dec 2023) noted having to delete a no-op merge commit because their repo does not use merge commits. That thread does not appear to have GitHub staff response on merge strategy or commit message customization, and does not mention release tooling impact.
• GitHub roadmap #627 (private forks support Actions): tangential, but another example of the advisory flow operating outside normal repository settings.

Concrete example

• Advisory: GHSA-m5ph-mmg5-6w5h (published 2026-06-26)
• Merge commit on default branch: 8db22b4
• Follow-up workaround PR with diagnosis: filecoin-project/filecoin-pin#601

Happy to provide more detail if useful. Thanks for continuing to invest in the advisory workflow.

[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. ⭐