You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is very similar to #9364, but instead of all branches pushing to a particular remote (git config remote.pushDefault origin), we can select just one (git config branch.<branch>.pushRemote origin).
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:
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-branch-push-remote-feature@{push}
fatal: cannot resolve 'simple' push to a single destination
Proposed Solution
Fortunately we know that if our push.default = current / simple (meaning local and remote branch have the same name) then with the branch.<name>.pushRemote telling us the correct remote we can concatenate these which will give us: origin/remote-branch-push-remote-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.
Description
Note
This is very similar to #9364, but instead of all branches pushing to a particular remote (
git config remote.pushDefault origin), we can select just one (git config branch.<branch>.pushRemote origin).When using a triangular workflow, it is possible to have a branch merge changes from
upstreamwhile pushing changes to afork. For example, imagine that we are working on a branchfeaturein our fork and we want to continually be rebasing onupstream/main, we could do that like so:First we clone the fork:
Then we check out a branch so that it is tracking
upstream/main:Then we set
branch.<branch>.pushRemotetooriginso that our new branch is pushed toorigininstead ofupstream:➜ git config branch.remote-branch-push-remote-feature.pushRemote origin ➜ test-repo git:(remote-branch-push-remote-feature) cat .git/config ... [branch "remote-branch-push-remote-feature"] remote = upstream merge = refs/heads/main pushRemote = originSo we create new a commit on the branch, and a new pull request (note that
git pushknew where to push to due tobranch.<name>.pushRemote):However when we try to view our newly created PR it fails because it is trying to find a PR from
mainsince that is the currentmergeentry in the branch config:Unfortunately, resolving
@{push}doesn't work because themergeentry for the branch config has a different branch name:➜ git rev-parse --abbrev-ref remote-branch-push-remote-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 thebranch.<name>.pushRemotetelling us the correct remote we can concatenate these which will give us:origin/remote-branch-push-remote-featureand 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.