# Reviewing

Every pull request in PullApprove has a review workspace — a diff-focused view for working through a change hunk by hunk. It tracks what you've looked at and identifies mechanically trivial changes so you can focus on the code that matters.

It complements your git host, not replaces it. Discussion and the actual approval still happen on GitHub or GitLab — the workspace is where you do the reading.

![The review workspace: review status, the diff, and your review queue](/assets/docs/img/review-workspace.0b60654.png)

## Layout

- **Review status** (left) - the overall verdict, each [scope's](./config/scopes/index.md) status and whose approvals are still needed, and submitted reviews.
- **Diff** (center) - the code, file-by-file or as one rolling diff, unified or split.
- **Files** (right) - your review queue, plus a **Browse** tab for the rest of the repo.

## The full branch, not just the diff

Most diff viewers show a few lines of context and make you expand the rest click by click. The workspace starts from the opposite default:

- **Files view** - each changed file's *complete contents*, with the changes highlighted in place. You review the change in the file as it will actually exist.
- **Diff view** - all files as one rolling diff, when you'd rather scan.
- **Browse** - the whole repo at the PR's revision. Open files that didn't change at all — a caller, a config, a related test — without leaving the review.

## Reviewing hunk by hunk

Mark each hunk **Reviewed** or **Needs work**, or **Save for later**. Files drop out of your queue as you go, and when everything is handled you submit your actual review on GitHub or GitLab as usual.

- Bulk actions cover whole files, filename patterns, and identical hunks repeated across files.
- Marks are private to you — stored in your browser, invisible to others, no effect on the PR.
- Marks are keyed to each hunk's *content*, not line numbers — pushes and rebases don't reset your progress.

## Trusted changes

Large diffs are padded with churn. PullApprove classifies hunks that are mechanically trivial:

| Family | Examples |
| --- | --- |
| Generated | Lock files (`package-lock.json`, `uv.lock`, ...) |
| Formatting | Whitespace, line wrapping, quote style, spacing |
| Comments | Comments added, removed, or modified |
| Imports | Imports added, removed, or reordered |
| Type hints | Type annotation changes |
| Files | Renames with no content change, empty files added |

![Trust rules menu with the Formatting and Comments families trusted, and a labeled hunk in the diff](/assets/docs/img/review-trust.ef26b08.png)

- **Conservative by design** - every rule recognizes one specific trivial shape and declines everything else. An unrecognized change is always shown, never hidden.
- **Opt-in** - labeled hunks are identified, not hidden. Focus the diff on a label's hunks to spot-check them, then trust the label — those hunks drop out of your queue.
- **Reversible** - untrust a label to bring its hunks straight back. Explicitly marking a hunk always overrides its label.
- **Personal** - like all review marks, trust says *you* don't need to read those hunks. It decides nothing for anyone else.

On very large diffs past a size limit, labels aren't computed and every hunk is shown normally.

### Trust never affects approval

Trust labels only change how the diff is presented — they are never an input to the review verdict. They don't satisfy a scope, don't count as an approval, and don't change who is required to review. Even a mislabeled hunk can never cause a PR to pass review automatically.