gh pr create --fill fails with confusing error: could not compute title or body defaults: fatal: ambiguous argument

[ssbarnea]

Describe the bug

I got an error below when running gh pr create --label skip-changelog --fill from inside a github action.

It is quite weird because I got the impression that the same action worked fine previously so it might be a recent regression.

The effective error comes from git which is called by gh. I checked and the previous command was able to correctly push the code to the new branch, one that has the same nable as the local branch (release/v0.9.0).

Still, gh pr create failed ugly.

Steps to reproduce the behavior

gh version 2.13.0

git push origin "release/${RELEASE_NAME}"
gh pr create --label skip-changelog --fill
# ^ that one fails

Expected vs actual behavior

[release/v0.9.0 d4bff6f] Release v0.9.0
 3 files changed, 8 insertions(+), 1 deletion(-)
remote: 
remote: Create a pull request for 'release/v0.9.0' on GitHub by visiting:        
remote:      https://github.com/ansible/ansible-language-server/pull/new/release/v0.9.0
remote: 
To https://github.com/ansible/ansible-language-server
 * [new branch]      release/v0.9.0 -> release/v0.9.0
could not compute title or body defaults: fatal: ambiguous argument 'origin/main...release/v0.9.0': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
/usr/bin/git: exit status 128

Logs

Code: https://github.com/ansible/ansible-language-server/blob/main/tools/release.sh#L60 Effect: https://github.com/ansible/ansible-language-server/runs/7234603626?check_suite_focus=true

[ssbarnea]

As the same code worked fine, I also observed something interesting, the release notes body contains -- inside and I suppose that it might be a bug inside --fill that might make it fail when the body contains these characters.

Still, when I run from the command line, even with --fill, it did work normally.

Shortly the sentence below should be tell us what happens

could not compute title or body defaults: fatal: ambiguous argument 'origin/main...release/v0.9.0': unknown revision or path not in the working tree.

Maybe there is some caching that makes it fail, as I push the branch right before trying to create the PR. Maybe that is too fast for github and it believes that the branch does not exists?

Should I put a sleep to make it reliable? How long?

[mislav]

@ssbarnea Since it was the git log origin/main...release/v0.9.0 command that failed and we know that a release/v0.9.0 branch for sure exists at this point, I'm inclined to think that it's the origin/main branch that doesn't exist in the context of your action run.

Note that actions/checkout by default makes a shallow checkout of the exact git ref that your action is running for: https://github.com/ansible/ansible-language-server/actions/runs/2629962634/workflow#L19

A shallow checkout means that origin/* tracking branches will not be available, including origin/main.

The solution would be to reconfigure your actions/checkout step with fetch-depth: 0 (warning: this checkout will be slower, as it fetching everything), or to find an alternative to --fill for your action.

[Chiitoo]

For what it is worth, I believe I was hitting this same thing with my workflow, and indeed, fetching with 'fetch-depth: 0' helped.

Thanks!

[samcoe]

Seems like this has been solved with fetch-depth: 0. Going to close this, please let me know if there is still a bug that needs to be discussed.

[tekumara]

Encountered this too:

gh pr create --fill -w
could not compute title or body defaults: failed to run git: fatal: ambiguous argument 'upstream/main...fix-state-allow_failure-exports': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'

(NB: gh is using upstream here because .git/config has gh-resolved = base for the upstream remote.)

I resolved this issue by first fetching the upstream remote: git fetch upstream

[minio-bot]

This works for me: https://github.com/cli/cli/issues/5896#issuecomment-1304723277

[pwm]

👋 @samcoe

I also started getting this out of nowhere after bumping the gh version (my home env is managed by nix).

I've been using this feature for a long time and it always worked fine before which tells me that something in gh changed recently that broke it.

The error is:

~/w(pwm/cac-updates|✔) [1] $ gh pr create --fill
Warning: 6 uncommitted changes
could not compute title or body defaults: failed to run git: fatal: ambiguous argument 'origin/...pwm/cac-updates': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'

[samcoe]

@pwm What version are you on now and what version did you update from? That will help narrow down what has changed.

Does using git fetch upstream fix the issue as others above have reported?

[jeffwidman]

I encountered this while testing a modification to a GitHub action workflow... the action worked fine on main, but then failed when I tested a PR branch.

My workflow was trying to create a PR back to main, and the problem was because when running the existing action on main, the initial actions/checkout step was checking out main, so everything worked. But on my PR branch that I was testing, the actions/checkout step was checking out the PR branch... since it's a shallow clone, it didn't know about main.

In my case, because the workflow itself was creating a PR, there was no need to run an additional git fetch, nor with: fetch-depth: 0 instead, I added with: ref: "main" to ensure the workflow always checked out main, even when run from a branch... this way the gh pr create step was always aware of main:

• https://github.com/dependabot/dependabot-core/pull/7335

[mislav]

Reopening since this seems to continuously affect people.

I believe that an ultimately correct approach for computing the git log between base and head branches is to ask the GitHub API rather than trying to query it locally.

Ref. https://github.com/cli/cli/issues/2691

[gdomingu]

This issue also effects users in codespaces for probably a reason similar to actions.

[TWiStErRob]

Assuming that you know the base branch of the PR, which is usually the default branch, instead of fetch-depth: 0, a more targeted (faster) workaround is:

git fetch origin main
gh pr create --fill

[ziadsarour]

Assuming that you know the base branch of the PR, which is usually the default branch, instead of fetch-depth: 0, a more target workaround is:

git fetch origin main
gh pr create --fill

Thank you, it works for me :)

[nerdCopter]

i've had this multiple times now until i realized that i was required to push my branch first rather than letting gh ask. i.e. git push --set-upstream [origin] [branch]