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 :
- 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
- Add some commits, and push to your fork :
git push origin HEAD
- Create the PR with
gh
:gh pr create
- 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 avoidgh
doinggit branch --set-upstream-to=origin/$(git branch --show-current)
orgit push -u origin $(git branch --show-current)
), a behaviour which can’t be disabled at the moment). - Enter title
- Edit body
- Submit
- 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
- Add progress to avoid cli/cli/issues/2691 — committed to Domochip/dayinfo2mqtt by Domochip a year ago
- Add sleep to avoid cli/cli/issues/2691 — committed to Domochip/dayinfo2mqtt by Domochip a year ago
- Add fetch to avoid cli/cli/issues/2691 — committed to Domochip/dayinfo2mqtt by Domochip a year ago
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 thatgh 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
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.This comment saved me: https://github.com/cli/cli/issues/575#issuecomment-1163143215
I use — gh pr create --title “The bug is fixed” --body “Everything works again”
but getting error
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-L363Sometimes 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: