Detect push target for local branches without upstream configuration

[mislav]

Commands such as pr status inspect the current branch and check its upstream configuration to see where it's pushed while resolving the branch to the associated PR.

Some branches might be pushed but have no upstream configuration (simple git push <remote> HEAD withough -u). Right now mechanisms such as prSelectorForCurrentBranch() don't recognize such branches as being published to a remote. We should perhaps iterate over all remotes and assume one to be a push target if we find a same-named tracking branch on one. (This will perhaps be prone to false-positives, but it's a marked improvement over current behavior.)

Reported by @rista404 #567 (comment)

[phil-blain]

Hi!

Ideally, the first step would be to use the existing Git logic for triangular workflows, see:

• remote.pushDefault,
• branch.<name>.pushRemote,
• @{push} revision syntax.

These configurations are unfortunately under-used because under-advertised (and are missing command-line options) but are specifically geared toward triangular workflows (i.e. GitHub-style forking workflows).

[phil-blain]

Adding a little more details:

The way I configure my feature branches is that they track the upstream branch in which they will eventually be integrated, and I push them to my own fork. Basically the configs above enable a workflow like this:

# first time only: setup 'origin' as the default push remote (I usually fork on GitHub, then clone my fork)
git config [--global] remote.pushDefault origin
# first time only: change default push behaviour to 'current' 
git config [--global] push.default current

# create a feature branch
git fetch upstream
git checkout -b my-feature upstream/master

# work work work

# push my branch to my fork
git push # no other arguments needed ! (does `git push origin my-feature`)

# work work work

# rebase on latest master
git fetch # no other arguments needed!  (does `git fetch upstream`)
git rebase # no other arguments needed! (does `git rebase upstream/master`)
# or in one step:
git pull --rebase  # (does `git pull --rebase upstream master`)

# or if your project's workflow uses merge:
git fetch # no other arguments needed!
git merge # no other arguments needed! (does `git merge upstream/master`)
# or in one step:
git pull # (does `git pull upstream master`)

So it enables a pretty cool workflow in my opinion, which feels really "natural".

So it would be great if gh could understand this workflow a little bit more. For example, I don't want gh to do git push -u origin my-feature when I open a pull request, because this defeats the purpose of the above configs; the "upstream" should stay upstream/master.

EDIT: here is a GitHub blog post dating from the release of Git 2.5, describing this workflow: https://github.blog/2015-07-29-git-2-5-including-multiple-worktrees-and-triangular-workflows/#improved-support-for-triangular-workflows

[mwaddell]

This makes gh pr status useless in github-actions - see pangaeatech/azure-test-deployment#8 (comment)

Is there a way to specify the PR URL when calling this?

[mwaddell]

Is there a way to explicitly set the upstream config from github actions as a workaround for this?

[stephanedaviet]

Maybe related (or not), gh pr create seems not to work in a fork configuration with only one remote configured and a fetch/push strategy to pull from upstream and push to fork. For instance:

origin  [email protected]:cli/cli.git (fetch)
origin [email protected]:org-where-forked/cli.git (push)

gh pr create gives then the following error: pull request create failed: GraphQL: Head sha can't be blank, Base sha can't be blank, No commits between <target-branch> and <current-branch>, Head ref must be a branch (createPullRequest).

gh version 2.11.3 (2022-05-25)

[mislav]

@stephanedaviet I would say it's related. To work around this, you can say:

gh pr create -H org-where-forked:<branch>

[gibfahn]

Worth noting that git itself tells you not to use such a configuration (e.g. from git help remote):

Note that the push URL and the fetch URL, even though they can be set differently, must still refer to the same place. What you pushed to the push URL should be what you would see if you immediately fetched from the fetch URL. If you are trying to fetch from one place (e.g. you're upstream) and push to another (e.g. your publishing repository), use two separate remotes.

(not saying gh shouldn't support it, just noting that it's not recommended)

[stephanedaviet]

Worth noting that git itself tells you not to use such a configuration (e.g. from git help remote):

Note that the push URL and the fetch URL, even though they can be set differently, must still refer to the same place. What you pushed to the push URL should be what you would see if you immediately fetched from the fetch URL. If you are trying to fetch from one place (e.g. you're upstream) and push to another (e.g. your publishing repository), use two separate remotes.

(not saying gh shouldn't support it, just noting that it's not recommended)

Good catch! It will make me re-examine my practice.

[sudddy]

@mislav I tried the same. Still couldn't create the pr. :'(

[sethidden]

EDIT: Spoke too soon, if you pull from any branch through magit it'll set the .merge config var and you'll run into the problem again.

Quick breadcrumb for future generations:
If somebody is using Emacs' magit to create branches and is running into the no pull requests found for branch "main" error, it's because you're running (magit-branch-create) (b c) with Create branch starting at: 'origin/main', if you pick a local (non-origin, so main instead of origin/main) branch, the branch.<branchname>.merge git config var won't be set to origin/main and gh cli won't be confused when running gh pr view --web etc.

[jtmcg]

Hey y'all! With the release of v2.66.1, we now support triangular workflows set up with remote.pushDefault, branch..pushRemote, and @{push} revision syntax for commands like gh pr view and gh pr status.

We plan to add support to gh pr create soon. Stay tuned

[jtmcg]

Expected Outcomes

• gh pr create supports triangular workflows assembled by remote.pushDefault, @{push} revision syntax,
  and branch..pushRemote, in that order of precedence (see ParsePRRefs, which adds support for this for other gh pr subcommands)
• An acceptance test is written for each of these scenarios. See pr-view-status-respects-branch-pushremote.txtar, pr-view-status-respects-push-destination.txtar, pr-view-status-respects-remote-pushdefault.txtar, and pr-view-status-respects-simple-pushdefault.txtar for examples on acceptance tests for these scenarios with the gh pr status command

Acceptance Criteria

Given git rev-parse --abbrev-ref @{push} resolves
when I run gh pr create
then I should create a pr with the headRef pointing at the @[push} return value

Given the branch.<branchName>.pushremote key is set on my current branch
when I run gh pr create
then I should create a pr with the headRef pointing at the remote value in the branch.<branchName>.pushremote key and the current branch name

Given the remote.pushDefault key is set on my current repo
when I run gh pr create
then I should create a pr with the headRef pointing at the remote value in the remote.pushDefault key and the current branch name

Given git rev-parse --abbrev-ref @{push} resolves
and/or given the branch.<branchName>.pushremote key is set on my current branch
and/or given the remote.pushDefault key is set on my current repo
when I run gh pr create
then I should create a pr with the headRef pointing at the given values in the following priority order: @[push} -> branch.<branchName>.pushremote -> remote.pushDefault

[gibfahn]

Two things that I use that I'm not sure are covered in the above criteria:

1. If the @{upstream} and @{push} are both set, the PR branch should be @{push} and the target branch should be @{upstream}
2. This should work even if my git repo has multiple github / GHE instances configured as different remotes.

e.g.

❯ git remote -v
up	https://github.mycorp.com/myorg/repo (fetch)
up	https://github.mycorp.com/myorg/repo (push)
fork	https://github.mycorp.com/me/repo.git (fetch)
fork	https://github.mycorp.com/me/repo.git (push)
pub	https://github.com/myorg/repo (fetch)
pub	https://github.com/myorg/repo (push)
pubfork	https://github.com/me/repo (fetch)
pubfork	https://github.com/me/repo (push)

The GH_HOST should be set according to the @{push} and @{up} configured for the current branch.

[jtmcg]

Two things that I use that I'm not sure are covered in the above criteria:

1. If the @{upstream} and @{push} are both set, the PR branch should be @{push} and the target branch should be @{upstream}
2. This should work even if my git repo has multiple github / GHE instances configured as different remotes.

e.g.

❯ git remote -v
up https://github.mycorp.com/myorg/repo (fetch)
up https://github.mycorp.com/myorg/repo (push)
fork https://github.mycorp.com/me/repo.git (fetch)
fork https://github.mycorp.com/me/repo.git (push)
pub https://github.com/myorg/repo (fetch)
pub https://github.com/myorg/repo (push)
pubfork https://github.com/me/repo (fetch)
pubfork https://github.com/me/repo (push)
The GH_HOST should be set according to the @{push} and @{up} configured for the current branch.

Good callout, @gibfahn. If not provided with the --repo flag, the base branch is currently determined by the following:

1. upstream
2. github
3. origin
4. Unstable list of other remotes

Once these updates are in, I think that we should be able to add @{upstream} support fairly easily (famous last words, though 😅 ). It's probably worth capturing this in another issue for follow up. I'll try to do that once we get this change in 👍