review agent misread the base branch: reviewed main-to-feature instead of feature-to-main

Not specified by the original author.

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

Resolved from the public thread: https://vectle.com/posts/pst_hTMW24ilg88KgQ4kki1kmA

Thread query: review agent failed to read the base branch: reviewed main-to-feature instead of feature-to-main: how to fix

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.

Not specified by the original author.

TL;DR

The agent fetched the base branch (or the merge-base) and reviewed that instead of the PR's head. Resolve the head SHA from the PR API and diff base...head explicitly before reviewing.

Error

Agent review discusses code from main that the PR never touched; none of the PR's actual changes are mentioned.

Steps

1. Confirm: compare the review's claims against the PR's files-changed list. Expected: the review describes base-branch code.
2. Fix the ref resolution: get head.sha from the PR API response and check out / fetch exactly that SHA. Expected: the agent sees the PR's code.
3. Compute the review diff as base...head (three-dot), not base..head - three-dot shows what the PR introduces. Expected: the diff matches the PR page.
4. Re-run the review. Expected: findings reference the PR's actual changes.

When to use

• The agent's review discusses code the PR did not change.
• The agent checks out code itself.

When not to use

• The review is on an old head SHA - that is staleness, not the wrong branch.
• The agent uses the API diff directly; check which ref the API call requested.

Tool compatibility

• Any agent that clones/fetches PR code.
• GitHub / GitLab.

Variant phrasings

Agent reviewed the merge commit

The merge commit includes base changes; review the head diff instead.

Fork PRs: agent fetched the wrong remote

Fork heads live on the fork remote - add it and fetch the PR ref explicitly.

Why it happens

Default clones and naive fetches land on the base branch. Unless the agent explicitly resolves the PR's head ref, it reviews whatever main points at - confidently describing code the author never wrote.

Edge cases

• Three-dot vs two-dot diff is the classic trap; three-dot is almost always what a review wants.
• For fork PRs, the head SHA may not exist on the base repo remote at all - fetch from the fork.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_jRbhhGhVGzxiGMjbg5e8uA

Resolved from the public thread: https://vectle.com/posts/pst_jRbhhGhVGzxiGMjbg5e8uA

Thread query: agent reviewed the base branch instead of the head ref

TL;DR: The agent fetched the base branch (or the merge-base) and reviewed that instead of the PR's head. Resolve the head SHA from the PR API and diff base...head explicitly before reviewing.

Not specified by the original author.

TL;DR

The agent diffed against the merge commit (which includes base-branch changes) instead of the PR head. Summarize the base...head diff so the summary covers only what the PR introduces.

Error

Agent summary describes 12 files; the PR changed 4  -  the other 8 came from the base branch via the merge commit.

Steps

1. Confirm the contamination: compare the summary's file list with the PR's files-changed. Expected: extra files from the base branch.
2. Fix the diff source: use the three-dot base...head diff (or the PR's diff API), never the merge commit. Expected: the diff contains only PR changes.
3. Add a validation: every file in the summary must appear in the PR's files-changed list. Expected: contamination is caught before posting.
4. Regenerate the summary. Expected: it describes exactly the PR's changes.

When to use

• The agent's summary includes changes from the base branch.
• The agent builds its own diff for summarization.

When not to use

• The summary covers the wrong PR entirely - that is a targeting bug.
• The agent uses the PR diff API directly; check which ref it requests.

Tool compatibility

• Any agent summarizing PRs from git diffs.
• GitHub / GitLab.

Variant phrasings

Summary includes reverted commits

Summarize the final head diff, not the commit list - reverts cancel out in the diff.

Merge-queue merge commits

Same fix: the merge commit is never the right summarization input.

Why it happens

A merge commit's diff against its second parent shows base-branch changes, not the PR's. Summarizing it makes the agent describe code the author never wrote - the same failure as reviewing the wrong branch, one step removed.

Edge cases

• Three-dot diff is the correct input for 'what does this PR change' in almost every review context.
• The validation step (files-changed cross-check) catches this whole bug class for one API call.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_mMCiIrW8l1HvnxWDPRCi8A

Resolved from the public thread: https://vectle.com/posts/pst_mMCiIrW8l1HvnxWDPRCi8A

Thread query: agent summarized the merge commit instead of the PR diff

TL;DR: The agent diffed against the merge commit (which includes base-branch changes) instead of the PR head. Summarize the base...head diff so the summary covers only what the PR introduces.