cli: Checking out an upstream branch creates error: "fatal: '/' is not a commit and a branch '' cannot be created from it

After some internal discussion, we think we have a path forward here. See below:

Actions

• Set upstream remote to fetch all branches in config but only automatically fetch the default

I just merged in a PR to address this issue. If you encounter this problem in the future git fetch upstream will be all that is needed to be able to then checkout the upstream branch. The team decided not to do the fetch implicitly as we were worried about performance when cloning large repos, which was the original reason for only fetching and tracking the default branch.

Hi, when gh adds the upstream remote, it only sets it up to track the default branches, but not any other branch (like enterprise-4.9). We did this to avoid having all upstream branches pulled automatically, but because of reports like yours, we might revisit that idea. In the meantime, here is how to fix this:

git remote set-branches upstream \*
git fetch upstream
git checkout -b enterprise-4.9 upstream/enterprise-4.9

@rolfedh hey - I’m unfortunately no longer at GitHub / working with the GH CLI team. It’s probably best to ping any active maintainers about the status of work/activities (/cc @mislav)

I’ve had this a few times and this is the first time I found this issue. Every other time I’ve just deleted the dir and done it via git clone instead and added the upstream remote manually.

It seems a real shame to have this confusion added in when it seems it should be a really simple procedure. It seems I should be able to fork a repo, clone it locally then check out PRs from the original repo just by running:

gh repo fork upstreamOrg/thingy
gh repo clone myUser/thingy
gh repo set-default
gh pr checkout 13

What makes it even more confusing is that it seems like it is all going well when it asks you to run gh repo set-default then immediately breaks when you try to check out the PR.

The workaround works nicely, (you can even use gh pr checkout <number> in lieu of the last git command it seems).

Hi, when gh adds the upstream remote, it only sets it up to track the default branches, but not any other branch (like enterprise-4.9). We did this to avoid having all upstream branches pulled automatically, but because of reports like yours, we might revisit that idea. In the meantime, here is how to fix this:

git remote set-branches upstream \*
git fetch upstream
git checkout -b enterprise-4.9 upstream/enterprise-4.9

This solved my issue my issue was unable to checkout to branch in the remote i was cloned the repository using
git clone --single-branch --branch <name> <repo_link> hence in the remote origin only set that specified branch cloned. by using the following i was able to add all the branches to local remote origin

git remote set-branches origin \*
git fetch origin
     or
git fetch origin test_branch
git checkout -b local_test origin/test_branch

I ran into this problem the other day as well. The solution offered by @mislav worked. The initial CLI error message provided by git, however, was unhelpful and not related to the issue.

This just hit me today. Your suggestion worked @mislav, thanks!

I ran into this today and it took me a while to piece together what was happening too 😃

it’s pretty confusing for cases where you use gh to file a PR, and then someone uses the UI to create a suggestion on your PR and you accept the suggestion. Then you have a new commit on your PR, but you can’t pull it down to your local branch because the ref pattern for the remote doesn’t match.

Just want to note that it looks like this can cause unexpected behavior with gh pr checkout.

To reproduce:

gh repo clone your-fork
gh pr checkout <id> # choose a PR from the upstream and select the upstream as the base repo
# get fatal: Cannot setup tracking information error