No upstream pull requests shown

[Y JR]

Search terms: remote, upstream
Using Bitbucket Server.

I do see upstream in “Create pull request” window. (below)

‌

But while upstream has 5 open PRs, I can’t see any. (below)

The “View in Browser” menu opens origin in browser, so ‘No pull requests found for this repository’ is true – but no way to view PRs for different remotes?

‌

[Nick Rundquist]

Tracked internally as https://pi-dev-sandbox.atlassian.net/browse/VSCODE-466

[Nick Rundquist]

As a workaround, you can add a new folder to your workspace that’s cloned from upstream and that should allow you to see those pull requests.

[Chris Golden]

I am also seeing this issue with the fork style workflow.

Looking at the code in src/bitbucket/bbUtils.ts the function firstBitbucketRemote it appears that origin is preferred as a match before upstream. Most user workflows expect origin to be the users own personal fork and the upstream to be their remote for pull-requests from their and other team members forks.

Is it possible to simply re-order the matching in firstBitbucketRemote to prefer the upstream remote first if it is present?

Also, other than for performance, is there no reason you cannot iterate through all of the remotes and check for pull requests on each?
If performance is the main blocker preventing that sort of generic solution, would a filter regex or similar for the remotes as a config option not allow users with multitudes of remotes the ability to reduce them to the ones they care about?

[Pramod Busam]

@Chris Golden Thanks for your feedback. We do have an item in our backlog to improve this use case.

If we provide a config to provide a list of remote names by priority e.g. ['upstream', 'origin', ... ], would that work for you (that will replace the hardcoded names in firstBitbucketRemote)? We would still like to limit it to 1 remote per repo for fetching pull request list for performance.

[Chris Golden]

For the Fork pull request use case for our teams yes the proposed config and priority would work for us thanks. It would be great to have the original Poster for this issue also confirm if the proposed works for them.

‌

[Pramod Busam]

We added a configuration option in version 2.6.0 to select the preferred git remote. Please re-open if you see any issues.