Reviewable Units

A diff is a list of files. A change is not. One pull request usually holds several logical changes — a migration, the API that reads it, the UI that calls the API — spread across files in whatever order the filesystem sorts them. Reading that top to bottom means holding the whole thing in your head at once, and it gets harder as pull requests get bigger. Assert groups the diff into clusters, each one a single logical change. Clusters nest, so a broad change breaks down into smaller ones, and every changed line lands in some cluster. A file can appear in several clusters, because a file often takes part in several changes. Each cluster has a generated title and summary, its own line stats, and the subclusters it breaks into.

​

Working through a pull request

Press V to open the cluster view. Assert gives you one unit at a time and the breadcrumb shows where you are. The cluster tree shows the whole hierarchy at once, with a progress ring on each unit. Progress is tracked per unit, so a half-finished pull request tells you what is left. Submit a verdict when you are done and Assert writes it back to GitHub as a review.

​

When someone pushes mid-review

Your progress carries forward. Assert maps your reviewed ranges onto the new commits: hunks that came through the push untouched stay reviewed, and hunks the push changed come back unreviewed. Re-review covers what you see on your second pass.

​

What Assert leaves out

Generated files, deleted files, and files too large to render collapse into placeholders, keeping the clusters focused on code worth reading. Clusters that touch UI carry a preview count. See Previews.