GitHub Hidden Whitespace: Why Pull Request Size Depends on the View

GitHub changed the pull request review view on October 22, 2026. Reviewers can now save a personal whitespace preference across pull requests, and GitHub says file counts and diff statistics follow the displayed diff.

The chart uses live GitQuick public Showcase data fetched on October 27, 2026. Total lines means additions plus deletions. Each row states its own snapshot window and eligible PR sample.

That creates an important measurement boundary. The diff a reviewer sees can be filtered. The pull request size stored in analytics can still represent the full raw change.

What GitHub shipped on October 22

GitHub's changelog announced two improvements to the Files changed page.

First, GitHub says, "You can save your whitespace visibility preference across pull requests." The options are Always show, Always hide, and Hide for this diff only. The saved choice is personal.

Second, new and deleted files now use the full width in split view. GitHub says this gives reviewers more room and reduces line wrapping.

The measurement detail is explicit: "File counts and diff statistics reflect the displayed diff." A reviewer hiding whitespace may therefore see different counts from a reviewer looking at the complete source diff.

This is useful interface behavior. Formatting-only changes can obscure logic changes. A persistent preference reduces repeated setup. It also means a screenshot of the Files changed page is no longer a stable definition of pull request size.

The review view and the analytics view answer different questions

GitHub's interface helps one reviewer inspect one pull request. It can hide whitespace, filter files, collapse viewed files, and show a rich dependency diff instead of source text. GitHub's review documentation treats these as navigation and inspection tools.

An analytics system needs a consistent definition across many PRs and runs. GitQuick reads the pull request metadata fields additions, deletions, and changed_files collected from GitHub. It defines total lines as additions plus deletions, then calculates a median and p90 over eligible PRs.

GitQuick does not reproduce each reviewer's personal whitespace filter. A GitQuick size value can therefore be larger than the statistics visible in a filtered GitHub diff.

Neither value is inherently wrong. The filtered view describes what the reviewer chose to display. The raw metadata describes the change GitHub recorded for the pull request.

What the current public snapshots show

GitQuick's public Showcase listed 21 organizations when this article was drafted on October 27, 2026. These three organization-wide snapshots cover public PRs created during their stated windows.

Every median and p90 in the table uses the PR-size sample shown in the same row. The table does not show how much of any PR was whitespace-only, generated, vendored, or mechanical.

The GitHub snapshot illustrates why the tail matters. Its typical eligible PR was 66 total lines, while p90 was 1,565. That does not prove that one in ten reviews was difficult. A large change can be generated or repetitive. A small change can alter critical behavior.

The organizations also have different repositories, contribution models, and automation. The rows are examples of distributions, not performance rankings.

How to measure pull request size after this change

Start by naming the layer you are measuring.

1. Raw pull request churn. Use additions plus deletions from consistent API metadata. Report median, p90, and the eligible sample.
2. Review surface. Record whether reviewers hid whitespace or excluded file types when the question concerns visible review effort. GitQuick does not currently expose this personal UI state.
3. Change type. Separate generated code, dependency lock files, formatting migrations, and mechanical refactors before interpreting a large value as complexity.
4. Review outcome. Pair size with time to first review, approval latency, review coverage, and change requests. Association does not establish causality.

Do not silently replace raw churn with a filtered screenshot count. Do not claim that the raw count equals the number of meaningful lines a reviewer examined. Store both definitions when both questions matter.

GitQuick's shipped PR Size Risk signal uses raw total-lines median and p90. The default rules trigger above 400 median lines or above 1,000 p90 lines, with higher critical thresholds. Those are triage defaults, not universal standards. The signal is intended to identify repositories and PRs for inspection, including generated and mechanical changes.

A practical review policy

Teams do not need one whitespace setting for everyone. They need a repeatable way to avoid missing content.

Reviewers can hide whitespace to isolate logic, then temporarily show the complete diff before approval when formatting or indentation carries meaning. Large mechanical changes should be separated from behavior changes when possible. Pull request descriptions should state when formatting, generated files, or dependency updates dominate the diff.

For measurement, keep the raw size series stable across runs. Add filtered or classified views as separate dimensions. Changing the metric definition after a UI update makes historical comparisons unreliable.

Takeaway

GitHub's saved whitespace preference makes pull request review more personal. It also makes the visible diff a weaker source for organization-wide size comparisons.

Use raw API metadata for a consistent PR-size trend. Use the filtered view to understand the review experience. Then inspect the large tail before treating line counts as complexity, effort, or quality.

For a related size analysis, read GitHub Stacked Pull Requests: What Shipped and What to Measure. For sample and coverage guidance, see Your Code Review Metrics Are Missing Part of the Story.

Explore the GitHub public Showcase, compare all public organizations, or try GitQuick on your organization.

Disclaimer: This analysis uses public GitHub metadata. Showcase snapshots cover the organization-wide windows shown above and were fetched on October 27, 2026. Pull request line counts are code-churn measures, not measures of semantic complexity, review effort, developer performance, code quality, or causality. Personal GitHub diff filters are not represented in GitQuick's PR-size metrics. GitQuick is not affiliated with or endorsed by GitHub or any organization mentioned.