Streamlining Code Review: Why GitHub Needs '--first-parent' for Productivity Tools

For developers and teams relying on precise commit history for debugging and tracking, GitHub's compare view (/compare/A...B) can often be a source of frustration rather than clarity. A recent discussion in the GitHub Community highlights a critical limitation: the compare view counts all commits reachable in the Git Directed Acyclic Graph (DAG), including those from merged feature branches, even if they weren't squash-merged into the main line. This isn't just a minor inconvenience; it significantly impacts the efficacy of software engineering productivity tools and the ability of technical leaders to quickly diagnose issues.

The Problem: Misleading Commit History in GitHub Compare

The core issue arises when a pull request is merged using a 'true merge commit' rather than a squash merge. While preserving branch history can be valuable in certain contexts, it dramatically inflates the commit count in GitHub's compare view. This makes it challenging for any system that depends on accurate, linear commit ranges, such as automated regression trackers, changelog generators, or audit tools.

Consider a real-world scenario from the dotnet/runtime repository, where a performance regression tracking tool (dotnet/perf-autofiling-issues) automatically files issues with a commit range:

• Start commit: d9cb3f3a (April 14, 2026)
• End commit: 62fda127 (April 15, 2026)
• Expected: Approximately 22 commits on the main branch's first-parent history, spanning about 14 hours. This is the relevant window for identifying a regression.
• Actual: GitHub's compare view shows a staggering 141 commits, including commits dating back three weeks to March 24.

This massive discrepancy was caused by a single PR (#126276) merged without squashing, which brought in 119 individual commits from its feature branch. These commits, though part of the DAG, are not part of the main branch's linear history. For a developer trying to pinpoint a performance regression, seeing 141 commits spanning three weeks instead of 22 commits from the last 14 hours renders the compare link utterly useless. It's like looking for a needle in a haystack, but the haystack just grew tenfold for no good reason.

Impact on Software Engineering Productivity and Delivery

The implications of this "DAG inflation" extend far beyond a single regression tracker. For product and delivery managers, and certainly for CTOs, clear visibility into what changes landed when is paramount. Misleading commit ranges directly affect:

• Regression Debugging: As seen, developers waste significant time sifting through irrelevant commits, delaying fixes and impacting engineering kpi examples related to mean time to resolution (MTTR).
• Changelog Generation: Automated tools attempting to generate concise changelogs between releases will pull in extraneous commits, making the changelog noisy and difficult to digest.
• Auditing and Compliance: For compliance or security audits requiring a clear history of changes within a specific timeframe, the current compare view can provide an overwhelming and inaccurate picture.
• Delivery Cadence: Anything that slows down the debugging or verification process ultimately impacts delivery speed and predictability.

When automated tooling, which is designed to boost software engineering productivity tools, provides inaccurate data, the trust in those tools erodes, and teams revert to manual, time-consuming processes. This is a direct hit to efficiency and developer experience.

Why Current Workarounds Don't Cut It

The discussion highlights several existing workarounds, but none offer a viable solution for automated systems that need linkable, precise, and UI-based commit ranges:

• git log --first-parent locally: Effective for local investigation, but critically, it's not linkable. Automated tools cannot embed a local command into a GitHub issue.
• GitHub API (date-based): Returns raw JSON, not a UI. Date-based filtering is imprecise for commit ranges, especially when trying to pinpoint changes between two exact SHAs.
• GitHub commits page with date filter: Again, date-based, not SHA-based. It cannot precisely bound a regression window, which is crucial for tools tracking changes between specific points.
• Enforce squash-merge for all PRs: This is often not feasible for large, active repositories like dotnet/runtime with hundreds of contributors, automated dependency flows (like Maestro), and legitimate use cases for preserving feature branch history. Mandating squash merges across the board can introduce its own set of workflow complexities and cultural resistance.
• Two-dot compare (A..B): GitHub still counts all DAG-reachable commits, yielding the same problematic result.

The common thread here is the lack of a linkable UI solution that respects the linear history of the main branch.

The Proposed Solution: A '--first-parent' Filter for GitHub Compare

The community's request is clear and pragmatic: a way to view the first-parent-only commit history between two SHAs directly within the GitHub compare UI. Several implementation options were suggested, all equally valuable:

1. A query parameter: e.g., /compare/A...B?first-parent=true. This is ideal for automated tooling, allowing precise, linkable control.
2. A toggle/checkbox in the UI: "Show first-parent commits only." This would empower developers doing manual investigations.
3. A separate view mode: Dedicated to showing only merge/squash commits on the mainline.

Any of these approaches would transform the compare view from a source of confusion into a powerful diagnostic tool, especially for repositories with mixed merge strategies. It would directly support the goals of software engineer performance goals by enabling faster debugging and clearer understanding of code changes.

Empowering Technical Leadership and Driving Productivity

Implementing a '--first-parent' filter isn't just about a niche feature; it's about enhancing the fundamental utility of GitHub for complex engineering workflows. For CTOs and technical leaders, this translates to:

• Improved Data Accuracy: Better insights into actual changes impacting mainline, leading to more reliable metrics and engineering kpi examples.
• Faster Issue Resolution: Reducing the time developers spend sifting through irrelevant commits means faster bug fixes and performance improvements.
• Enhanced Developer Experience: Providing tools that work intuitively and accurately boosts morale and trust in the platform.
• Support for Diverse Workflows: Acknowledging and supporting repositories that cannot or choose not to enforce a single merge strategy.

This feature would be a significant win for any project that uses commit ranges for tracking, auditing, or changelog generation, especially those linking to GitHub compare views from automated tooling. It’s a clear path to boosting software engineering productivity tools and making GitHub an even more indispensable part of the development lifecycle.

The request for '--first-parent' filtering has surfaced before, only to be marked dormant. It's time for this essential feature to gain the traction it deserves. Let's make GitHub's compare view truly reflect the linear history that often matters most for rapid diagnosis and efficient delivery.