pr view and pr status should respect remote.pushdefault #9364
Description
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-repoThen 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/mainThen 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/47However 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.