Feature Request: Support --first-parent filtering in GitHub compare view

[ilonatommy]

🏷️ Discussion Type

Product Feedback

💬 Feature/Topic Area

Other

Body

The problem

GitHub's compare view (/compare/A...B) counts all commits reachable in the Git DAG, including commits from merged feature branches. This makes the compare view unusable for commit-range-based tooling when even a single PR in the range was merged without squashing.

Our use case

We maintain a performance regression tracking tool (dotnet/perf-autofiling-issues) that automatically files issues when benchmark regressions are detected in dotnet/runtime. Each regression issue includes a commit range (start SHA → end SHA) identifying the window where the regression was introduced. We link to GitHub's compare view so developers can quickly see which PRs landed in that window and narrow down the culprit.

Real-world example

• Start commit: d9cb3f3a (Apr 14, 2026)
• End commit: 62fda127 (Apr 15, 2026)
• Expected: ~22 commits on the main branch's first-parent history (spanning ~14 hours)
• Actual: GitHub shows 141 commits, including commits dating back 3 weeks to March 24

The cause: one PR in that range (#126276 — "Add sources from iltrim hackathon") was merged as a true merge commit (not squash-merged), bringing in ~119 individual commits from its feature branch. Those branch commits are reachable in the DAG and get included in the compare view, even though they are not part of the main branch's linear history.

This makes the compare link useless for our regression investigation workflow — developers see 141 commits spanning 3 weeks instead of the 22 relevant main-branch commits from the last 14 hours.

Why existing workarounds don't work

Workaround	Problem
git log --first-parent locally	Not linkable — we need a URL to embed in auto-filed GitHub issues
GitHub API /repos/.../commits?since=...&until=...	Returns JSON, no UI; date-based filtering is imprecise for commit ranges
GitHub commits page with date filter (/commits/main/?since=...&until=...)	Date-based, not SHA-based; can't precisely bound a regression window
Enforce squash-merge for all PRs	Not feasible for large repos like dotnet/runtime with 900+ contributors, automated Maestro dependency-flow merges, and legitimate use cases for preserving branch history
Two-dot compare (A..B)	GitHub still counts all DAG-reachable commits, same result

What we'd like

A way to view the first-parent-only commit history between two SHAs in the GitHub compare UI. This could be:

1. A query parameter on the compare URL, e.g. /compare/A...B?first-parent=true
2. A toggle/checkbox in the compare UI: "Show first-parent commits only"
3. A separate view mode that shows only merge/squash commits on the mainline

Any of these would make the compare view usable for commit-range-based tooling in repos with mixed merge strategies.

Impact

This affects any project that:

• Uses commit ranges to track regressions, generate changelogs, or audit changes
• Has contributors who occasionally use merge commits instead of squash
• Links to GitHub compare views in automated tooling, bots, or issue templates

For dotnet/runtime specifically, the perf regression tracker generates dozens of issues per week, each with a compare link. A single non-squashed merge in the range makes every one of those links misleading.

Prior discussions (closed/dormant)

This has been requested before but never gained traction:

• Commit View - --first-parent · Discussion #58142 — marked dormant
• Is there a way to list only the merge commits on a branch via the web UI? · Discussion #70224 — marked dormant, received only an AI-generated non-answer

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