Re-review without re-reading

You reviewed a PR on Tuesday. It's Friday — seven new commits later, and the author has cleaned up the commit history along the way. GitHub has a Changes since last review view for moments like this, but once commits get rewritten it gives up. What you're left with is the whole change, top to bottom. Your old comments hang off lines that may or may not still exist. You end up reviewing the whole thing as if you'd never seen it.

Why this keeps happening

The diff view answers one question well: what does this change look like right now? It was never built to answer the other question — what changed since I last looked? Answering that needs a different view: one pinned to a past version, able to cut through rebase noise, and letting you pick which past version to compare against.

A different approach

Keep the version that was there before every push. Now you have a list of every version the PR has ever been. Click any version to see what it added. Select a range — from the one you last read to the current one — for a single combined diff of everything new in between.

That's the whole idea. It has a name — interdiff, or diff of diffs. The concept isn't new. VisualJJ brings it to GitHub pull requests.

How it works in VisualJJ

Install VisualJJ in your editor. Open a repo. Open the Evolution panel from the top bar (the versions icon), then click a PR in the dashboard to load its history.

The panel docks to the bottom, listing every version of the PR that's ever been pushed — newest at the top. Click any row and a diff opens showing what that version added compared to the one before it. Arrow up and down to move through versions quickly.

Hold Shift and click a second row to pick a range. The diff now shows everything that changed across that span as a single combined view — useful when you want "what's new since I last reviewed" in one shot.

Rebases show up as rows but produce empty diffs. A rebase doesn't change the author's work; it just moves it onto a newer base. VisualJJ cancels that noise out so you don't waste time re-reading code that wasn't re-written.

The author doesn't need to change anything

VisualJJ reads the version history from GitHub directly — the same data GitHub has always stored but never surfaced as a first-class list. Nothing about the walkthrough above requires the PR's author to install anything. They don't need to use VisualJJ. They don't need to know you installed it.

The author's workflow is unchanged. Yours is the only one that gets better.

Though — friends don't let friends re-read PRs. Tell your teammates.

When you reach for it

The specific moments where this earns its place:

  • The author addressed your comments. You want to verify, fast.
  • A PR you reviewed days ago has updates. You want to check only what's new.
  • A PR went through several rounds of AI-assisted edits. You want to see each round separately rather than as a blob.
  • You paused mid-review and came back later. You want to pick up where you stopped.
  • You want to understand how a PR evolved — not just what it ended up as.

Try it

PR evolution is part of VisualJJ Pro. Start a free 30-day trial, open any PR in your editor, open the Evolution panel from the top bar, and click the PR.

Next time an author says they addressed your comments, pick the version you last read and see exactly what they did. No more reviewing the whole thing as if you'd never seen it.