`pr view` and `pr status` should respect `remote.pushdefault`
Description
When using a triangular workflow, it is possible to have a branch merge changes from upstream while pushing changes to a fork. For example, imagine that we are working on a branch feature in our fork and we want to continually be rebasing on upstream/main, we could do that like so:
First we clone the fork:
➜ gh repo clone williammartin/test-repo Cloning into 'test-repo'... remote: Enumerating objects: 160, done. remote: Counting objects: 100% (45/45), done. remote: Compressing objects: 100% (25/25), done. remote: Total 160 (delta 33), reused 21 (delta 20), pack-reused 115 Receiving objects: 100% (160/160), 24.89 KiB | 2.26 MiB/s, done. Resolving deltas: 100% (53/53), done. From https://github.com/williammartin-test-org/test-repo * [new branch] main -> upstream/main * [new tag] vDraftTriage -> vDraftTriage * [new tag] vDraftyBoi -> vDraftyBoi ! Repository williammartin-test-org/test-repo set as the default repository. To learn more about the default repository, run: gh repo set-default --help ➜ cd test-repo
Then we check out a branch so that it is tracking upstream/main:
➜ git checkout -b remote-push-default-feature upstream/main branch 'remote-push-default-feature' set up to track 'upstream/main'. Switched to a new branch 'remote-push-default-feature' ➜ cat .git/config [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true ignorecase = true precomposeunicode = true [remote "origin"] url = https://github.com/williammartin/test-repo.git fetch = +refs/heads/*:refs/remotes/origin/* [branch "main"] remote = origin merge = refs/heads/main [remote "upstream"] url = https://github.com/williammartin-test-org/test-repo.git fetch = +refs/heads/*:refs/remotes/upstream/* gh-resolved = base [branch "remote-push-default-feature"] remote = upstream merge = refs/heads/main
Then we set remote.pushdefault to origin so that all branches are pushed to origin instead of upstream:
➜ git config remote.pushDefault origin
➜ cat .git/config
...
[remote]
pushDefault = originSo we create new a commit on the branch, and a new pull request (note that git push knew where to push to due to remote.pushDefault):
➜ git commit --allow-empty -m "remote-push-default-feature" && git push [remote-push-default-feature 0aeb519] remote-push-default-feature Enumerating objects: 2, done. Counting objects: 100% (2/2), done. Delta compression using up to 10 threads Compressing objects: 100% (2/2), done. Writing objects: 100% (2/2), 273 bytes | 273.00 KiB/s, done. Total 2 (delta 1), reused 0 (delta 0), pack-reused 0 remote: Resolving deltas: 100% (1/1), done. remote: remote: Create a pull request for 'remote-push-default-feature' on GitHub by visiting: remote: https://github.com/williammartin/test-repo/pull/new/remote-push-default-feature remote: To https://github.com/williammartin/test-repo.git * [new branch] remote-push-default-feature -> remote-push-default-feature ➜ gh pr create -H williammartin:remote-push-default-feature --title remote-push-default-feature --body remote-push-default-feature Creating pull request for williammartin:remote-push-default-feature into main in williammartin-test-org/test-repo https://github.com/williammartin-test-org/test-repo/pull/47
However when we try to view our newly created PR it fails because it is trying to find a PR from main since that is the current merge entry in the branch config:
➜ gh pr view no pull requests found for branch "main"
Unfortunately, resolving @{push} doesn't work because the merge entry for the branch config has a different branch name:
➜ git rev-parse --abbrev-ref remote-push-default-feature@{push}
fatal: cannot resolve 'simple' push to a single destinationProposed Solution
Fortunately we know that if our push.default = current / simple (meaning local and remote branch have the same name) then with the remote.pushDefault telling us the correct remote we can concatenate these which will give us: origin/remote-push-default-feature and we'll be able to find the PR!
Additional context
This is already implemented by #9208, I'm just capturing the specific enhancement separately as it was kind of hard for me to understand as someone that's never used these features before.