Describe the feature or problem you’d like to solve

For PRs, if you use git's @{push} branches feature, you can have a much nicer workflow, and also automatically know which branch to raise PRs against.

For example, before I raise PRs:

$ git rev-parse --abbrev-ref --symbolic-full-name @
my_new_feature

$ git rev-parse --abbrev-ref --symbolic-full-name @{push}
fork/my_new_feature

$ git rev-parse --abbrev-ref --symbolic-full-name @{upstream}
up/master

However I may be on a different branch with a different remote in the same repo (for things with both public and private pairs of fork/upstream remotes, one in github.com and one in GHE):

$ git rev-parse --abbrev-ref --symbolic-full-name @
upstreaming_my_new_feature

$ git rev-parse --abbrev-ref --symbolic-full-name @{push}
pubfork/upstreaming_my_new_feature

$ git rev-parse --abbrev-ref --symbolic-full-name @{upstream}
pubup/master

As I already have these configured, it's painful to have to have gh guess them, and in cases where the --branch is ambiguous (e.g. up and pubup both have a master branch), it seems to pick one at random (and setting GH_REPO doesn't help).

Proposed solution

Ideally these would just be used as defaults, and gh pr create would just work with the above configuration.

However what might also be useful (and more flexible) would be to allow passing refs as the --base and --head branch refs (I know the latter doesn't exist right now).

That way it could be gh pr create --base=@{upstream} --head=@{push}

Additional context

Right now things sometimes work if you only have two remotes, depending on whether the heuristics in context.go work: