review agent failed to read the base branch: reviewed main-to-feature instead of feature-to-main: how to fix
Fixes a review agent reviewing the inverted diff by always computing the diff in PR direction, base to head, and sanity-checking that the changed files match the PR. Use when the agent's findings describe base-branch code as if the PR introduced it. Triggers: backwards findings, wrong-direction diffs. Not for wrong-base selection, or merge-base subtleties.
TL;DR
The agent diffed in the wrong direction, so it reviewed the base branch's code as if the PR added it. Always compute the diff from base to head, the PR direction, and sanity-check that the changed files match the PR's file list before reviewing.
The error
review agent failed to read the base branch: reviewed main-to-feature instead of feature-to-main: how to fix
(findings describe code that exists on main and that the PR never touched)Steps
1. Print the diff range the agent actually used
Log the exact refs or SHAs passed to the diff command or compare call. Expected output: the range is visibly backwards, such as feature...main instead of main...feature.
2. Fix the direction to base-to-head
Use git diff base...head for the three-dot merge-base diff, or the compare endpoint with basehead set to base...head. Expected output: the diff shows what the PR introduces, nothing else.
3. Sanity-check the changed files against the PR
Compare the diff's file list to the PR's reported changed files. Expected output: the two lists match. A mismatch means the direction or the refs are still wrong.
4. Re-run the review
Expected output: findings reference only code the PR actually changed.
When to use
- Findings describe base-branch code the PR never touched
- The changed-file list does not match the PR
- Comments appear on code that predates the PR
When not to use
- The wrong base branch was selected entirely (fix the base ref, not the direction)
- Merge-base subtleties in long-lived branches (rebase first)
- The PR genuinely touches old code paths
Tool compatibility
- git diff two-dot and three-dot ranges; the GitHub compare API basehead parameter
- GitLab merge request diffs are always base-to-head by construction
- Any agent that fetches its own diff, LLM or deterministic
Variant phrasings
reviewer commented on code the PR did not touch
The signature symptom of an inverted or mis-scoped diff. Steps 1 and 3 diagnose it in seconds.
reviewed main instead of the PR
The agent diffed the base against itself or fetched the wrong ref. Verify the head ref resolves to the PR branch.
findings reference files not in the PR
Same check as step 3. If the file lists diverge, stop and fix the diff before trusting any finding.
Why it happens
Diff direction is a silent parameter: git diff A...B and git diff B...A both succeed and both look like diffs. Swapping base and head inverts which side counts as new, so the reviewer confidently analyzes the wrong code. Nothing errors, which is why it survives to production.
Edge cases
- The base branch moved mid-review: re-fetch the base ref before computing the diff, or findings may reference already-merged code.
- PRs targeting a release branch: the base is the release branch, not main. Read the base from the PR metadata instead of hardcoding.
- Two-dot vs three-dot: two-dot shows everything different between the tips, three-dot shows what the PR introduces. For reviews, three-dot is almost always what you want.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_hTMW24ilg88KgQ4kki1kmA