pr view and pr status should respect @{push} where possible #9363
Description
Describe the feature or problem you’d like to solve
Given I have a centralized workflow, when I am using push.default = current I expect that PRs on my current branch will be found via pr view and pr status.
First we clone the repo:
➜ gh repo clone williammartin-test-org/test-repo
Cloning into 'test-repo'...
remote: Enumerating objects: 159, done.
remote: Counting objects: 100% (89/89), done.
remote: Compressing objects: 100% (67/67), done.
remote: Total 159 (delta 35), reused 53 (delta 14), pack-reused 70
Receiving objects: 100% (159/159), 25.11 KiB | 6.28 MiB/s, done.
Resolving deltas: 100% (50/50), done.
Then we set the push.default to current which indicates that when pushing, the name of the local branch will be the same as the remote branch.
➜ cd test-repo
➜ git config push.default current
Then we check out a feature branch and set it's upstream to origin/main. This means that git pull will pull from the main branch into our feature branch.
➜ git checkout -b test-feature
Switched to a new branch 'test-feature'
➜ git branch --set-upstream-to origin/main
branch 'test-feature' set up to track 'origin/main'.
➜ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
ignorecase = true
precomposeunicode = true
[remote "origin"]
url = https://github.com/williammartin-test-org/test-repo.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "main"]
remote = origin
merge = refs/heads/main
[push]
default = current
[branch "test-feature"]
remote = origin
merge = refs/heads/main
We can check that the @{upstream} revision syntax correctly resolves to origin/main.
➜ git rev-parse --abbrev-ref test-feature@{upstream}
origin/main
When we push we can see that it created a new remote branch test-feature:
➜ git:(test-feature) git push
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
remote:
remote: Create a pull request for 'test-feature' on GitHub by visiting:
remote: https://github.com/williammartin-test-org/test-repo/pull/new/test-feature
remote:
To https://github.com/williammartin-test-org/test-repo.git
* [new branch] test-feature -> test-feature
When we create a commit and create a new PR from the branch:
➜ git commit --allow-empty -m "empty commit" && git push
[test-feature 9464a82] empty commit
Enumerating objects: 1, done.
Counting objects: 100% (1/1), done.
Writing objects: 100% (1/1), 189 bytes | 189.00 KiB/s, done.
Total 1 (delta 0), reused 0 (delta 0), pack-reused 0
To https://github.com/williammartin-test-org/test-repo.git
299ae17..9464a82 test-feature -> test-feature
➜ gh pr create -B main -H test-feature --title test-feature --body test-feature
Creating pull request for test-feature into main in williammartin-test-org/test-repo
https://github.com/williammartin-test-org/test-repo/pull/43
Sadly pr view can't find the PR I just created based on the branch I'm in:
➜ gh pr view
no pull requests found for branch "main"
This happens because gh is using the merge config entry for the branch. It loads the branch config here and falls into this branch when determining the GQL variable.
However, we can see that at this point the @{push} revision syntax resolves correctly to origin/test-feature.
➜ git rev-parse --abbrev-ref test-feature@{push}
origin/test-feature
So let's use that!
Proposed solution
When we load the branch config, let's also fetch the result of git rev-parse --abbrev-ref test-feature@{push} and if it is set, when we fall into this branch we can use the result of that rather than the merge entry.
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.