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

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

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?

@ssbarnea

@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.

Fix pr creation on release

Fix pr creation on release (#407)

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!

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.

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

This works for me: #5896 (comment)

@samcoe

👋 @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>...]'

@pwm

@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?

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:

Ensure we start from main even if workflow run from a branch dependabot/dependabot-core#7335

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. #2691

fix: add fetch-depth:0

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

Fix release process (part 3) (#3828)

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

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 :)

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]

I have this problem primarily in git worktrees.

I am slowly switching to a setup where I have a single bare clone and git worktree add from it.

gh pr create works without problems, gh pr create --fill cause the error from the OP.

Trying to fix cli/cli#5896

Fix `pr create --fill` when local branch name differs from remote

Navigation Menu

Repository navigation

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

Describe the bug

Steps to reproduce the behavior

Expected vs actual behavior

Logs

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Describe the bug

Steps to reproduce the behavior

Expected vs actual behavior

Logs

Activity

ssbarnea commented on Jul 7, 2022

mislav commented on Jul 13, 2022

Chiitoo commented on Sep 21, 2022

samcoe commented on Oct 20, 2022

tekumara commented on Nov 6, 2022

minio-bot commented on Feb 3, 2023

pwm commented on Mar 10, 2023

samcoe commented on Mar 12, 2023

jeffwidman commented on May 17, 2023

mislav commented on May 17, 2023

gdomingu commented on Aug 22, 2023

TWiStErRob commented on Oct 25, 2023

ziadsarour commented on Oct 28, 2023

nerdCopter commented on Apr 18, 2024

NobbZ commented on Mar 1, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions