warning: remote HEAD refers to nonexistent ref, unable to checkout

Question

This seems like a popular error for different causes.

I've got a simple bare git repo called "kiflea.git", I clone it like this:

git clone git://kipdola.be/kiflea.git

Then git tells me: warning: remote HEAD refers to nonexistent ref, unable to checkout.

And yes, there are no versioned files in the map, except for the .git directory. Anyway, the only thing I need to do is:

cd kiflea
git checkout master

And it works, all the files are there. But I thought cloning a repo automatically checks out the master, so what is going on exactly, and how do I fix it?

I have noticed that, after I do the git checkout master bit, this gets added to my local .git config file:

[branch "master"]
    remote = origin
    merge = refs/heads/master

It's probably interesting to know that this git repository used to be an svn repository in a distant past.

Ps: when browsing the bare repository using gitweb, there clearly is a master branch there: http://kipdola.be/gitweb/?p=kiflea.git;a=summary

Answer 1

The warning: remote HEAD refers to nonexistent ref, unable to checkout. means that the remote (bare) repository contains branch reference in the file called HEAD with a value that does not match any published branch in the same repository. In practice, that file defines which branch should be checked out by default after cloning the repository.

Note that the warning only means that git didn't do checkout. The cloned repository is otherwise just fine. Just do git branch -a to see possible branches and git checkout the-branch-you-want to workaround the issue.

This usually happens because the default contents for that file (.git/HEAD or plain HEAD for bare repositories) is literal string ref: refs/heads/master which says that if somebody is going to clone this repository, they should by default clone the branch refs/heads/master. By default Git will create local branch without the refs/heads/ prefix (that is, master by default). Try git help symbolic-ref for more information.

The problem with this situation is that Git does not provide a method for modifying remote symbolic refs so either you use something the Git hosting provider has implemented (e.g. Settings - Default branch in GitHub if you have admin rights) or you have to use branch name master as the default branch (because that's the default content for the file HEAD and if you cannot modify that file, you'll be stuck with master forever).

If you have a shell access to your remote git repo, you can simply open a shell on the remote matchine and execute cd path/to/git/repo; git symbolic-ref HEAD refs/heads/XYZ where XYZ is the branch name you want to use by default.

One way to hit this issue is to create a new remote bare repo with no commits and then do git push name-of-the-remote my-special-branch-name which will result in bare repository containing a single branch my-special-branch-name but the HEAD symbolic ref still contains the default value pointing to master. As a result, you'll get the aforementioned warning. If you cannot modify the remote HEAD file, you can publish your branch using syntax git push name-of-the-remote my-special-branch-name:master meaning that your local branch called my-special-branch-name should be published as branch master on the remote.

Answer 2

I had same issue when creating a bare repo.

I solved it just cloning the repo, creating a local master branch and then pushing master to the remote repo.

1. clone the repo

$ git.exe clone --progress -v "the remote path" "my local path"

2. create a master branch locally.

$ git checkout -b master

3. commit something in the local branch

$ git add readme.md 
$ git commit –m "Added readme"

4. Push local master on the remote

$ git push origin master

Answer 3

If there is no master branch actually available, check the following; If there is a file named 'packed-refs' inside the '.git' folder, open it and you could find all references listed.

Something like below;

# pack-refs with: peeled fully-peeled 
e7cc58650190bd28599d81917f1706445d3c6d8b refs/tags/afw-test-harness-1.5
^cfae4f034e82591afdf4e5ed72279297d0eee618
6afe1bcfa4bd74de8e0c8f64d024e1cc289206df refs/tags/afw-test-harness-2.1
^c32f7fa495d4b44652f46c065fcd19c3acd237a6
72f2e4284dfbf27c82967da096c6664646bbdd19 refs/tags/android-1.6_r1
^50992e805e758e2231f28ec2127b57a1a9fd0ddc
0cbd528cad1cee9556098b62add993fc3b5dcc33 refs/tags/android-1.6_r1.1

Then use;

git checkout refs/tags/xxxx

Or

git checkout 'HASH value'

to checkout the required version. Thank you.

Answer 4

In my case the repo was empty.

git checkout --orphan master

git add some_file
git commit -m 'init'
git push origin master 

Answer 5

• Set the default branch to an existing branch.

• Then re-clone the repo.

GitHub - Changing the default branch

In BitBucket you can set it in the repository settings.

Answer 6

I ran into this issue when I created a bare repository, cloned it, and then then never pushed a master branch. I was testing a new git client and it never created the upstream master.

I fixed it by creating a new master branch and pushing it, which then allowed me to cherry-pick all my local commits on to that new master, and then pushing it. Once that was done I was able to clone just fine.

Answer 7

It is late(2021) answer but will help others.

Quick fix run this git command git symbolic-ref HEAD refs/heads/main

Thanks @alexey-vazhnov

When you create a bare repo using git init --bare it set ref: refs/heads/master in HEAD file but when you clone this bare repo its default branch is main, this is the issue so you need to change HEAD file and put main' instead of masater` i.e.

ref: refs/heads/main

Answer 8

This question is 10 year old. This is how I solved it now:

Suppose you are cloning your repo using clone command than you will see logs like this:

git clone https://abcgit-repo.abccoolrepo

Cloning into 'abcgit404.sasasasmy cool repo'... remote: Counting objects: 198, done remote: Finding sources: 100% (26/26) Receiving objects: 80% (176/219)ed 208 (delta 0)Receiving objects Receiving objects: 100% (219/219), 49.09 KiB | 163.00 KiB/s, done. warning: remote HEAD refers to nonexistent ref, unable to checkout.

Now to solve remote HEAD refers to nonexistent ref, unable to

First checkout your branch you will see logs like this:

1. git checkout remotes/origin/mainline

HEAD is now at xyz

2. See all branchs your current branch will have * in front of it

git branch -a

*(HEAD detached at origin/mainline)
remotes/origin/a
remotes/origin/b
remotes/origin/c
remotes/origin/d
remotes/origin/mainline

3. Copy the branch name from above and run git checkout checkout -b

Eg checking out mainline:

git checkout -b remotes/origin/mainline

*origin/mainline remotes/origin/a
remotes/origin/b
remotes/origin/c
remotes/origin/d
remotes/origin/mainline

This will solve the issue

Answer 9

For Gitlab, even it shows you are on a default branch (e.g. master) you might not actually be on it, setting it again fix it, like so:

1. Create a new branch, maybe asd
2. settings > repository > Default Branch, which shows the default branch is master
3. Set it to asd
4. Set it back to master
5. Delete asd branch

Done, now your default branch is master

Answer 10

I seemed to fix it with:

git checkout -b  master
git push

This created the default master, and then I could checkout my other branches

Answer 11

Even though this error was displayed - my project was still connected to the corresponding repository - I ran the git branch command and saw the appropriate branches - then I ran git checkout *branchname and BOOM - all was well.

Answer 12

Yes this is related to your git clone trying to checkout a branch different than master. Just do this

git clone user@git-server:project_name.git -b branch_name /some/folder

This will help you clone the exact branch via its branch name.

Answer 13

I have had the same issue because I was not using anymore the master branch and it went lost in both my local and remote repository.

The remote repository had still the HEAD set to master, I have changed it to one of the remote branch I actually use and everything works fine.

If you can access your remote repository:

• Go to your remote_repo.git;
• Edit HEAD file
• Change ref: refs/heads/master to ref: refs/heads/your_branch

Answer 14

I'd guess that it's the leading * in the commit log that is somehow fooling the remote server.

I can browse around the repo's web interface using some of the menu links, but others fail with a 404 - Unknown commit object or similar, particularly from the summary page.

See if you can amend that last commit message and then force push the update to see if that fixes it. There may be a bug in the server demon. If it does fix it it would be worth reporting on the git list git@vger.kernel.org (plain text messages only)

Answer 15

There's definitely something wrong with your remote repository. You might be able to fix it by making a new clone of the repository. Also pushing a new commit to the master branch might work too.