Git cannot checkout remote branch despite `git ls-remote origin` showing it exists

Question

I'm struggling to checkout a remote branch that I know exists, because it shows up with git ls-remote:

$ git ls-remote
242d56fbd8d8af67df3157bd047252f5580e3df8    HEAD
242d56fbd8d8af67df3157bd047252f5580e3df8    refs/heads/master                                         
517af0f6de9a3db846c4bde693a11ccb52092aee    refs/heads/foobar

When I try to checkout, I get an error:

$ git checkout refs/heads/foobar
error: pathspec 'refs/heads/foobar' did not match any file(s) known to git

I've tried all sorts of things to no avail:

• git fetch --all doesn't change anything, neither does git fetch origin
• git branch -v -a doesn't show it

Going through many SO answers, I finally stumbled upon something that worked, but I have no clue why:

git fetch origin foobar:foobar

Answer 1

It turns out I had originally shallow-cloned the repository with --depth 1. This caused a subtle change in .git/config. My remote.origin.fetch was set to:

$ git config remote.origin.fetch         
+refs/heads/master:refs/remotes/origin/master

This meant that git never looked at the origin branch for anything but master when running things like checkout, fetch, branch, with the exception of git ls-remote which seems to ignore that config setting.

Fixing is easy:

git config remote.origin.fetch '+refs/heads/*:refs/remotes/origin/*'

though beware that this undoes the benefits of shallow cloning. You will pull quite a lot of the history that way.

Alternatives may be (untested): git fetch --unshallow

To fetch the branch just once, use git fetch origin foobar:foobar . But this way you will also get a lot of the history and you may need to do this fetch again in the future.

If you just want to track that one branch in addition to the others, it may be possible to change the fetch config, but I'm not quite sure how exactly.

As most people don't use shallow-cloning, most existing StackOverflow questions/answers don't address this particular issue. Thanks to kenorb for pointing me this way in this answer.