fix: fetch remote base branch before PR range context to prevent stale diffs

[zerone0x]

Summary

Fixes #1487

When creating a pull request via the git button, the range context (commit log and diff used to generate the PR title/body) was computed using baseBranch..HEAD where baseBranch referred to the local branch ref (e.g. main). If the local ref hadn't been fetched since previous PRs were merged upstream, the range would include all old commits from previously merged PRs, causing:

• PR titles to reflect the first PR's content rather than the current changes
• PR bodies to accumulate descriptions from all past changes

Root cause: runPrStep in GitManager.ts called readRangeContext(cwd, baseBranch) with a potentially stale local branch ref. Since the push step only pushes the current feature branch (not fetching the base), the local main could be many commits behind origin/main.

Fix: Before computing the range context, fetch the remote tracking ref for the base branch (e.g. origin/main) and use it for the range computation. This ensures the diff only contains commits not yet present upstream, so each PR gets a fresh title and body based solely on its own changes.

The fix is conservative:

• If baseBranch already contains a remote prefix (e.g. origin/main), it's used as-is
• If the fetch fails (e.g. offline, no remote), it falls back to the local ref (preserving current behavior)
• The baseBranch variable is still used for PR targeting — only the range computation uses the refreshed remote ref

Test plan

• Create commits on a feature branch, commit+push+PR via git button — verify title/body match the changes
• Merge that PR upstream, then create new commits on the same branch
• Commit+push+PR again — verify the new PR title/body only reflect the new changes, not the previously merged ones
• Test offline/disconnected scenario — verify graceful fallback to local ref
• Verify cross-repository fork PRs still work correctly

---

Note

Medium Risk
Adds a network git fetch (30s timeout) during PR creation and changes which commits/diffs are used to generate PR title/body; failures fall back to prior local-ref behavior.

Overview
Ensures PR title/body generation uses an up-to-date base by fetching the base branch’s remote tracking ref before computing the range context in runPrStep.

If the base branch already includes a remote prefix it’s used directly; otherwise it fetches headContext.remoteName (or origin) and prefers remote/<baseBranch> for readRangeContext, falling back to the local baseBranch on fetch/verify failure.

^{Written by Cursor Bugbot for commit a00a0dc. This will update automatically on new commits. Configure here.}

Note

Fetch remote base branch before computing PR diff range to prevent stale diffs

In configurePullRequestHeadUpstream, the base branch ref used for readRangeContext is now resolved to its remote-tracking counterpart before computing PR content. The code fetches the base branch from the appropriate remote (using headContext.remoteName or falling back to origin), verifies the ref exists via git rev-parse --verify, and uses it if successful. On any error, it falls back to the local base branch name.

• Behavioral Change: PR commit and diff summaries may differ from before when the local base branch was behind the remote.

^{Macroscope summarized a00a0dc.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: e058a2c0-0609-4326-b135-8f3ed450d0d4

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[cursor]

Slash check misidentifies local branches as remote refs

Medium Severity

The baseBranch.includes("/") check is intended to detect remote-prefixed refs like origin/main, but it incorrectly matches any branch name containing a slash (e.g., release/1.0, feature/main, hotfix/critical). These are common local branch naming conventions. When resolveBaseBranch returns such a name — via git config, extractBranchFromRef, or getDefaultBranch — the code skips the remote fetch and uses the potentially stale local ref, defeating the fix for issue #1487 in those cases.

 

[zerone0x]

Closing in favor of a simpler fix using git's built-in --cherry-pick --right-only flags.

[zerone0x]

Closing in favor of a more targeted fix that regenerates PR title/body when an existing PR is found, rather than returning stale metadata.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

There are 2 total unresolved issues (including 1 from previous review).

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[cursor]

Fork workflows fetch base branch from wrong remote

Medium Severity

In cross-repository (fork) workflows, headContext.remoteName is the remote for the feature branch's push target (the fork), not the upstream repo where the PR base branch lives. Fetching the base branch (e.g., main) from the fork remote can retrieve a stale or missing ref, potentially making the range context worse than the original local ref. For example, when origin = upstream and the branch pushes to myfork, the old code used local main (tracking upstream), but the new code fetches myfork/main (the fork's possibly-never-synced main).