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