Skip to main content
| Change Stack gives you two independent decisions about a diff: how the changes are organized, and how the two sides are laid out. On top of that sit the controls you reach for when the default view is not enough β€” expanding context, filtering whitespace, checking blame, peeking at a definition, rendering a non-code file, and collapsing the summaries you do not need. This page covers the reading surface itself. Moving between layers and files is covered in navigation, and what a finding means is covered in findings. What you read here is the snapshot, not the live branch: the diff belongs to one review run against one head commit. See snapshots.

Semantic or line diff

The first choice is how changes are organized. Semantic is the default. It groups a change around the function, class, or other entity it touches rather than around line numbers, which is usually how you want to read a refactor.
Files without a usable semantic result fall back to the line diff even when semantic mode is selected. You do not have to switch modes to read them, and nothing is hidden β€” you get the line diff for those files and the semantic view for the rest.

Split or unified

The second choice is layout. Split is the default. Organization and layout are separate preferences with separate defaults, so semantic and split are what you get until you change either one.

Expand context

Each expansion adds 20 lines. For added and deleted files, expansion is unavailable when the available content exceeds 200,000 characters β€” beyond that you still get the diff hunks, but you cannot open the surrounding unchanged lines. Modified files are not subject to that character limit; expansion is available when both the old and current content can be loaded. In semantic mode, expansion has its own setting: Context is the default. Semantic context expansion is available only when both the old and the current file content were loaded and at least one side is non-empty, so a newly added file with no prior content, or a file whose other side could not be loaded, offers no semantic expansion.

Filter whitespace-only changes

You can filter whitespace-only changes out of the diff, which is what you want on a reformatting commit or a change that re-indents a large block.

Blame

You can inspect blame for the code in the diff, without leaving the review to open the file on your provider. Blame lookups are best effort. Provider timeouts, content that is not available, or incomplete textual matching can return no result β€” a blank answer means the lookup did not resolve, not that the line has no history.

Code Peek

Code Peek lets you look at definitions and references connected to code in the diff without leaving the review.
Code Peek uses bounded provider search and heuristic matching, so it can omit valid definitions or references. Treat it as a fast lookup that saves you a trip to the repository, not as a language server. When completeness matters β€” an audit of every caller, for example β€” verify in your editor. Like blame, code navigation is best effort and can return no result at all.

Rich diffs for non-code files

Not every changed file is source code. For prose, rendered documents, and images, Change Stack can show you the rendered result rather than the markup, with controls for how the before and after are compared.

Prose and rendered documents

For a file that has a rendered representation, you choose what you are inspecting and how much of it to show at once. Reading the rendered output tells you what the reader will see; reading the source tells you what actually changed in the file. Both are worth a look on a documentation change, which is why they are separate controls rather than one toggle.

Images

For images, you choose how the two versions are placed against each other and how they are sized. Side by side is what you want for two unrelated images; onion skin and swipe are what find a small pixel shift between two versions of the same asset.

Collapse low-complexity summaries

On a large change, the summaries attached to trivial ranges are noise that pushes the interesting ones off the screen. Change Stack scores each range as low, medium, or high complexity, and collapses summaries below a threshold you set. Low is the default, so the ranges that took real thought stay open and the rest fold away. The threshold is global, and you can override an individual range when you want to read a collapsed one.

Appearance and layout

You choose the page theme, the syntax theme, the code font, and how the diff and the rails are presented. Settings are grouped into three: theme, which covers the page theme and code font; view, which covers diff and layout presentation; and filters, which covers finding and diff filters. The page theme is dark, light, or system, and system is the default. You pick a dark syntax theme and a light one independently β€” fourteen and eleven of them respectively, the usual editor themes β€” and the one in effect follows the page theme, so a theme switch does not send you back to the settings menu. Eight monospace fonts are available. Both rails can be dragged within bounds: the right panel is clamped to 300–560 pixels and the left rail to 220–420 pixels. Navigate a change covers what they hold. If you are signed in, your layout, appearance, filtering, and interaction preferences are retained, so the reading setup you build on one pull request is the one you get on the next.

Very large GitHub changes

A GitHub pull request large enough to defeat the compare API is recovered through a raw diff with hard bounds on file count, patch size, line length, and fetch time; past those bounds the diff is refused rather than truncated silently. Provider support has the numbers.

What’s next

Understand findings

Read what CodeRabbit found in the code you are looking at, and how it ranks it.

Provider support

Check what your Git provider supports before you rely on a control.