A coding agent reports that your feature branch removed a logging fix. You inspect the feature commits and find no such deletion. The logging change exists only on the base branch, which advanced after the feature started.

Before arguing about the finding, ask what the agent compared. A valid diff can answer the wrong review question.

This guide is for maintainers and developers delegating pull request reviews. The deliverable is a small comparison receipt: enough context to explain which snapshots the agent inspected and which work it did not inspect.

Methodology and selection criteria

We reviewed the official Git diff and merge-base manuals and GitHub's branch comparison documentation on October 8, 2026. The branch example below is hypothetical. We did not execute a repository fixture or benchmark a review skill.

The selection criterion is the intended question: compare two current states, or examine a branch's contribution since shared history. Those are different tasks. Neither operation, by itself, proves that the proposed code will run correctly after integration.

Choose endpoints before choosing syntax

The Git manual defines git diff A..B as a comparison between A and B, equivalent to supplying those two commits without dots. git diff A...B instead compares a merge base with B. These forms concern diff endpoints, not the commit-set ranges used by other Git commands. Git diff documentation.

Use the distinction to write the review request before collecting output:

Review question	Proposed comparison	What the reviewer should not infer
How do these two snapshots differ?	Explicit A and B commits	Every difference was authored on B
What did this topic branch introduce relative to shared history?	Recorded merge base to B	The branch already contains every change on A
Is the eventual integrated application correct?	Separate integration assessment	A clean-looking diff is sufficient evidence

Our recommendation is to attach the question to the report. A heading such as “changes” is too ambiguous when people are reviewing different endpoints.

A diverged-branch thought experiment

Imagine a common commit C. Main adds a log statement and reaches M. Independently, a feature branch adds a search field and reaches F. Assume the changes touch unrelated files and neither branch merges the other.

Comparing M with F can display the log statement as absent on the F side. That observation does not mean a feature commit deleted it. For the branch-contribution question, the relevant starting point in this simplified history is C.

A useful finding would say: “The feature snapshot does not include the main-only logging change.” A stronger claim that the feature author removed logging would need different evidence.

This distinction changes the next action. A maintainer might request integration checks, but should not ask the agent to restore or rewrite files merely to make an incorrectly scoped review look clean. A review request is not permission to mutate the branch.

Record the actual ancestry decision

Git's merge-base documentation describes best common ancestors. In histories with criss-cross merges, there can be multiple best merge bases; without --all, which one is output is unspecified. Git merge-base documentation.

Our workflow should therefore stop when its assumed single-base model is not established. An absent result is not permission to invent an empty starting tree. Incomplete local history, unavailable references or unrelated histories need an explicit investigation outcome.

For ordinary reviews, record the immutable commit IDs resolved for the requested base and head, the selected comparison mode and the merge base actually used where applicable. Branch names remain helpful labels, but the receipt should preserve what was reviewed even if those names later move.

Do not solve an evidence gap by resetting the user's checkout, discarding local edits or force-pushing a rewritten branch. Request the missing context or perform only the authorized history retrieval needed to inspect it.

Reconcile local findings with GitHub

GitHub documents that pull requests use a three-dot comparison. It also explains that a two-dot diff can change when the base advances, even when the topic branch does not. GitHub branch comparisons.

If a local report disagrees with the pull request, compare the recorded base and head first. Then inspect the comparison mode and any path or display filters. Do not immediately interpret different output as a hosting bug.

A practical receipt for an agent review should contain:

The requested review question and repository identity.
Base and head commit IDs, with their human-readable branch labels.
Comparison mode and ancestry decision.
Included paths and explicit exclusions.
Whether local uncommitted work was outside scope.
Findings, their evidence locations and unresolved coverage gaps.

Keep staged and unstaged work separate from committed branch review. The agent should not stage a user's edits just to include them in a convenient snapshot.

Proposed acceptance checks

Before adopting an automated review workflow, create an authorized, disposable fixture that covers four situations: a base-only change, a feature-only change, both branches editing the same area, and missing ancestry information.

Write expected report language before running it. The important check is not whether every report has the same number of lines. It is whether the agent distinguishes observed snapshot differences from claims about authorship and integration.

Repeat a review after the base label moves. A new receipt should expose the changed input instead of presenting contradictory findings as though they came from identical evidence. These are proposed checks, not tests performed for this article.

Limitations and the next handoff

Correct endpoints do not establish correctness, security or merge readiness. Review depth, generated files and runtime behavior still need their own evidence. Complex ancestry may require human interpretation rather than an automatic choice of the smallest diff.

Use the skills directory to find review candidates, then ask whether their reports preserve comparison context. If a finding leads to a rollback, our Git undo guide addresses the separate question of which existing edits must survive.

The first useful question for a coding reviewer is not “How many issues did you find?” It is “Which two states did you actually inspect?”