cli: 'gh pr create' fails if skipping pushing with "GraphQL error: Head sha can't be blank, Base sha can't be blank, No commits between master and , Head ref must be a branch"

Describe the bug

Under some circumstances (not sure exactly why, see below), if I choose to skip pushing the current branch, PR creation fails with the following error:

GraphQL error: Head sha can’t be blank, Base sha can’t be blank, No commits between master and <branch>, Head ref must be a branch"

This is on 1.4.0 but also happened on 1.3.1.

Steps to reproduce the behavior

I think this should reproduce the problem. I’m pretty sure the bug is linked to the upstream configuration for the current branch :

  1. Create a topic branch, and set the Git upstream configuration to the upstream branch where this topic will eventually be integrated (see https://github.com/cli/cli/issues/575): git checkout -b my-topic upstream/master
  2. Add some commits, and push to your fork : git push origin HEAD
  3. Create the PR with gh: gh pr create
  4. Choose “Skip pushing the branch” when asked where to push. I already pushed it myself, and I don’t want gh to mess with my upstream configuration (i.e. I want to avoid gh doing git branch --set-upstream-to=origin/$(git branch --show-current) or git push -u origin $(git branch --show-current)), a behaviour which can’t be disabled at the moment).
  5. Enter title
  6. Edit body
  7. Submit
  8. Experience error: pull request create failed: GraphQL error: Head sha can't be blank, Base sha can't be blank, No commits between master and my-topic, Head ref must be a branch

Expected vs actual behavior

I expected the PR creation to succeed. The GraphQL error seems to imply that gh is making a incorrect API request because (I assume) it can’t correctly compute the required arguments.

Logs

## Git state before attempting PR creation
# upstream branch is upstream/master
$ git rev-parse --symbolic-full-name  @{upstream}
refs/remotes/upstream/master
# current branch is one commit ahead of its upstream
$ git log --oneline --decorate @{upstream}..HEAD
494173a586 (HEAD -> fix-linkgit-git1, origin/fix-linkgit-git1) git.txt: fix typos in 'linkgit' macro invocation
# current branch is already pushed to my fork
$ git  log --oneline --decorate origin/$(git branch --show-current)..HEAD
# empty

# configured remote for 'gh' is 'ggg', which I do not have push access to:
$ git config --get-regexp  'remote.*.gh-resolved'
remote.ggg.gh-resolved base

# Try creating the PR:
$ gh pr create 
? Where should we push the 'fix-linkgit-git1' branch? Skip pushing the branch

Creating pull request for fix-linkgit-git1 into master in gitgitgadget/git

? Title Fix typo in 'linkgit' macro invocation
? Body <Received>
? What's next? Submit

X operation failed. To restore: gh pr create --recover /var/folders/lr/r6n2057j0dzd4gdb614fp0740000gp/T/gh303112606.json

pull request create failed: GraphQL error: Head sha can't be blank, Base sha can't be blank, No commits between master and fix-linkgit-git1, Head ref must be a branch

Another thing I noticed while debugging this: If I choose to open the PR against my own fork (-R phil-blain/git), it works., even if I do not skip pushing the branch.

About this issue

  • Original URL
  • State: open
  • Created 4 years ago
  • Reactions: 16
  • Comments: 19 (3 by maintainers)

Commits related to this issue

Most upvoted comments

Why not just check the local hashes? in the case above, “test” and “origin/test” point to the same hash, so it means the branch was pushed… Then you can’t have “false positives” , no ?

Also, I think the doc could be clearer about the “owner:branch” syntax for the  --head argument. I only tried it after reading the code, and only afterwards realized that gh pr create --help had “gh pr create --base develop --head monalisa:feature” as the last example…

For me a branch is a Git term, and “phil-blain:test” is not a branch, so I think the documentation could be clearer in that regards.

I kept getting this error - I was calling the wrong branch name in --head. Hopefully that can help someone down the line.

For those still facing this issue, I was doing something similar in a script

git push …
gh pr create …

which resulted in a race condition of the remote branch being created. This was fixed by adding a sleep in between these two commands. A bit sloppy but it works.

I use — gh pr create --title “The bug is fixed” --body “Everything works again”

but getting error

It was one commit ahead of @{upstream} (upstream/trunk), but it was fully pushed to @{push} ( origin/test).

We don’t have support for @{push}, so only @{upstream} was taken into account, and since there was a mismatch, gh could not determine where the branch was pushed. https://github.com/cli/cli/blob/4750e4ae18735375ef91e84fa5c148783743c379/pkg/cmd/pr/create/create.go#L353-L363

Sometimes I think that our branch push detection is trying to be too smart. Maybe we can just assume that a branch was pushed to a remote if there is a same-named branch on the remote. That could be prone to false positives, but I think they would be rarer than current false negatives.

Interestingly, I tried with --head phil-blain:$(git branch --show-current) instead, and this succeeded:

{
    "query": "\n\t\tmutation PullRequestCreate($input: CreatePullRequestInput!) {\n\t\t\tcreatePullRequest(input: $input) {\n\t\t\t\tpullRequest {\n\t\t\t\t\tid\n\t\t\t\t\turl\n\t\t\t\t}\n\t\t\t}\n\t}",
    "variables": {
        "input": {
            "baseRefName": "trunk",
            "body": "Trying to reproduce https://github.com/cli/cli/issues/2691",
            "draft": false,
            "headRefName": "phil-blain:test",
            "repositoryId": "MDEwOlJlcG9zaXRvcnkyMTI2MTMwNDk=",
            "title": "Test PR to reproduce https://github.com/cli/cli/issues/2691"
        }
    }
}