How Open‑Code‑Review Handles Pull Request Merging: A Technical Deep Dive

Open‑Code‑Review (OCR) never executes a git merge; instead, it computes the merge‑base between branches and generates a diff against the pull request head, feeding those changes to an LLM for review without altering repository state.

The Alibaba open‑source tool Open‑Code‑Review automates code review using large language models, but unlike CI/CD pipelines, it deliberately avoids modifying repository state. Understanding how open‑code‑review handles pull request merging reveals a read‑only architecture designed for safety and precision, where the tool treats PRs as semantic ranges rather than merge operations.

Why OCR Never Merges Your Pull Request

OCR is architected as a read‑only analysis engine. According to the source code in cmd/opencodereview/review_cmd.go, the tool never invokes git merge or writes to the repository. Instead, it resolves the reviewable range between two Git references, computes their common ancestor (the merge‑base), and examines the differences. This approach ensures that reviewing a pull request remains a completely safe operation that cannot corrupt branch history or introduce unintended commits.

The 7‑Step Diff‑Based Review Workflow

When you invoke ocr review --from main --to feature-branch, the tool executes a precise sequence to extract the changes for AI analysis.

1. Parsing CLI References and Validating Inputs

The process begins in cmd/opencodereview/review_cmd.go, where the reviewOptions struct captures the --from, --to, and --commit flags. The function validateReviewRefs performs critical security checks to ensure supplied refs are valid commits and do not start with a hyphen (-), preventing ref‑option injection attacks.

// From review_cmd.go – validating refs before any Git operation
opts := &reviewOptions{
    from:    *fromFlag,
    to:      *toFlag,
    commit:  *commitFlag,
}
if err := validateReviewRefs(opts); err != nil {
    return err
}

2. Determining the Review Mode

OCR supports three distinct review modes: workspace, commit, and range. The function reviewModeFromOptions (or tool.ParseReviewMode in later refactors) determines which mode applies based on which flags you provided. Range mode activates when both --from and --to are specified, which is the standard pattern for pull request reviews.

3. Computing the Merge‑Base for Range Reviews

For range reviews, OCR must identify the common ancestor to establish the baseline of changes. In cmd/opencodereview/delegate_cmd.go, the mergeBase() method executes git merge-base to find this point:

func (dc *delegateContext) mergeBase(ctx context.Context) string {
    if dc.opts.from == "" || dc.opts.to == "" {
        return ""
    }
    out, err := dc.gitRunner.Run(ctx, "merge-base", dc.opts.from, dc.opts.to)
    if err != nil {
        return ""
    }
    return strings.TrimSpace(string(out))
}

If the mode is not range (e.g., reviewing a single commit), the function returns an empty string, indicating no merge‑base calculation is required.

4. Configuring the FileReader with Merge Context

With the merge‑base resolved, review_cmd.go constructs a tool.FileReader that points to the target ref (the PR head) while retaining the merge‑base for comparison:

mode := tool.ParseReviewMode(opts.from, opts.to, opts.commit)
ref, _ := mode.RefValue(opts.to, opts.commit)

fileReader := &tool.FileReader{
    RepoDir: cc.RepoDir,
    Mode:    mode,
    Ref:     ref,
    Runner:  cc.GitRunner,
}

This configuration allows the file reader to present the exact delta introduced by the pull request.

5. Generating the Diff with First‑Parent Semantics

The actual diff generation occurs in internal/diff/git.go. When processing merge commits, OCR uses the --diff-merges=first-parent flag to render changes relative to the mainline parent. This produces the same view as git show <merge‑commit>, showing only the changes introduced on the feature branch side:

out, err := p.runGit(
    ctx,
    "-c", "core.quotepath=false",
    "show", "--no-ext-diff", "--no-textconv",
    "--find-renames", "--src-prefix=a/", "--dst-prefix=b/",
    "--no-color", "--diff-merges=first-parent",
    "-U"+fmt.Sprint(DiffContextLines), "--end-of-options", p.commit,
)

6. Feeding Changes to the LLM Tool Registry

The computed diff flows into cmd/opencodereview/buildToolRegistry, which instantiates built‑in tools including FileRead, FileFind, CodeSearch, and CodeCommentProvider. These tools allow the LLM to query specific lines, search patterns, and propose comments based on the diff content.

7. Emitting Review Results Without Repository Changes

Finally, agent.New initializes the review agent with the tool registry, ag.Run executes the LLM analysis, and emitRunResult outputs the review comments. At no point does OCR write to the Git object database or modify working tree files.

Critical Safety and Implementation Details

Merge‑Base Calculation Logic

The merge‑base computation is strictly conditional. As implemented in delegate_cmd.go, the function returns early with an empty string unless both --from and --to are provided. This ensures that single‑commit reviews or workspace reviews skip unnecessary Git calculations.

Handling Merge Commits in the Diff

When a pull request contains merge commits (from syncing with the base branch), the --diff-merges=first-parent flag ensures the review focuses only on the feature branch's unique changes. This aligns with standard GitHub/GitLab PR diff views, which show changes relative to the merge base rather than the full three‑way merge result.

Ref‑Option Injection Protection

The validateReviewRefs function in review_cmd.go explicitly rejects references beginning with -. This prevents attackers from crafting malicious branch names like --force that could be interpreted as command flags when passed to Git subprocesses.

Practical Examples

Review a pull request by specifying the base and head branches:

ocr review --from main --to feature-branch

Review using a specific merge commit SHA (produces identical results for the changes introduced):

ocr review --commit abcdef1234567890

Programmatically configure the review range in Go:

// Resolve review mode from CLI options
mode := tool.ParseReviewMode(opts.from, opts.to, opts.commit)
ref, _ := mode.RefValue(opts.to, opts.commit)

// Initialize file reader with computed merge-base context
fileReader := &tool.FileReader{
    RepoDir: cc.RepoDir,
    Mode:    mode,
    Ref:     ref,
    Runner:  cc.GitRunner,
}

Summary

• No actual merge execution: OCR remains read‑only and never runs git merge, ensuring repository safety.
• Merge‑base dependency: The tool uses git merge-base in delegate_cmd.go to establish the common ancestor for range reviews, determining exactly what changed in the PR.
• First‑parent diff semantics: Merge commits are rendered using --diff-merges=first-parent in internal/diff/git.go, showing only feature branch changes.
• Injection resistance: validateReviewRefs in review_cmd.go sanitizes inputs to prevent ref‑option attacks.
• Range‑based architecture: Pull requests are treated as diff ranges between two refs, not as merge operations.

Frequently Asked Questions

Does Open‑Code‑Review actually merge my pull request?

No. OCR is strictly a review tool and never modifies your repository. It computes the diff between the base and head commits using the merge‑base as a reference point, but it never creates merge commits or alters branch pointers.

How does OCR determine which changes belong to a pull request?

OCR calculates the merge‑base (the common ancestor commit) of the source and target branches using the mergeBase() function in cmd/opencodereview/delegate_cmd.go. It then diffs the head commit against this base, capturing exactly the changes introduced by the pull request.

Can OCR handle pull requests that contain merge commits?

Yes. When processing merge commits, the diff generator in internal/diff/git.go uses the --diff-merges=first-parent flag. This renders the merge commit as changes relative to the mainline parent, ensuring the review focuses only on the feature branch's unique contributions rather than the entire merged history.

Is it safe to run OCR on pull requests from untrusted contributors?

Yes. The tool performs validation in validateReviewRefs to reject references starting with hyphens, preventing command injection. Additionally, because OCR only reads from the repository and never writes or merges, it cannot be used to alter repository state even if provided with malicious inputs.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}