Boosting Software Engineering Productivity Tools: The Need for `first-parent` in GitHub Compare

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.

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, it dramatically inflates the commit count in GitHub's compare view. This makes it challenging for software engineering productivity tools that depend on accurate, linear commit ranges.

Real-world example:

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

This 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, rendering the compare link useless for quick investigations.

Impact on Software Engineering Productivity Tools

The discussion author, ilonatommy, maintains a performance regression tracking tool for dotnet/runtime. This tool automatically files issues when benchmark regressions are detected, including a commit range (start SHA → end SHA) and a link to GitHub's compare view. The intention is to help developers quickly identify the culprit PRs within that specific window.

When the compare view includes extraneous commits, it directly hinders the tool's effectiveness, making debugging significantly harder and impacting engineering KPI examples like Mean Time To Resolution (MTTR) for regressions. Developers are presented with an overwhelming and irrelevant history, undermining their software engineer performance goals related to efficient code investigation.

git log --first-parent A...B

This local Git command provides the desired linear history, but it's not linkable, which is crucial for automated tooling.

Current Workarounds Fall Short

Several workarounds were considered and dismissed due to their limitations:

• Local git log --first-parent: While accurate, it's not linkable, making it unsuitable for embedding in automated issues.
• GitHub API (/repos/.../commits?since=...&until=...): Returns JSON, lacking a UI, and date-based filtering is imprecise for commit ranges.
• GitHub commits page with date filter (/commits/main/?since=...&until=...): Also date-based, not SHA-based, preventing precise bounding of a regression window.
• Enforcing squash-merge for all PRs: Not feasible for large repositories like dotnet/runtime with 900+ contributors, automated dependency merges, and legitimate use cases for preserving branch history.
• Two-dot compare (A..B): Still counts all DAG-reachable commits, yielding the same problematic result.

Proposed Solutions for Enhanced Clarity

To restore the utility of GitHub's compare view for commit-range-based tooling, the community suggests several approaches:

• Query Parameter: A simple addition to the URL, e.g., /compare/A...B?first-parent=true.
• UI Toggle: A checkbox in the compare UI labeled "Show first-parent commits only."
• Separate View Mode: A dedicated view that displays only merge/squash commits on the mainline.

Implementing any of these solutions would significantly enhance the effectiveness of software engineering productivity tools and workflows in projects with mixed merge strategies.

The Broader Impact on Engineering KPIs and Performance Goals

This feature affects any project that uses commit ranges for regression tracking, changelog generation, or auditing changes, especially those that integrate with automated tooling and bots. For dotnet/runtime, where dozens of regression issues are generated weekly, a single non-squashed merge can render all related compare links misleading, directly impacting developer efficiency and the ability to meet software engineer performance goals.

This isn't a new request; similar discussions have been raised before but haven't gained sufficient traction. It's clear that a robust solution for viewing first-parent-only commit history in the GitHub UI is a persistent need for many large, active communities.