149

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

Jelle De Loecker
  • 20,999
  • 27
  • 100
  • 142
  • 2
    What does `git ls-remote origin` show you? – CB Bailey Aug 10 '12 at 05:39
  • It's the same before or after the `checkout master` bit: `25f600739343a7ce32d6311a1e6140870774810b refs/heads/master` – Jelle De Loecker Aug 10 '12 at 18:24
  • 1
    It looks like the remote repository has lost (or never had) its `HEAD`. Do you have direct access to it? If so, see [here](http://stackoverflow.com/questions/4848607/git-fatal-no-such-ref-head/4848878#4848878) – CB Bailey Aug 10 '12 at 21:52
  • 2
    If you clone a repository and do not specify the branch, it tries to use the remote head. As explained below in the answers, you cannot influence which branch directly. However by checking out a different branch at clone time, you avoid this check. In your case it seems master exists but remote head points somewhere else, so use: `git clone -b master ` – eckes Sep 16 '14 at 00:58

15 Answers15

216

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

Mikko Rantalainen
  • 14,132
  • 10
  • 74
  • 112
  • 26
    Note that the warning only means that git didn't do `checkout`. The cloned repository is otherwise just fine. Do `git branch -a` to see possible branches and `git checkout the-branch-you-want` to "fix" the issue. – Mikko Rantalainen Mar 26 '13 at 07:34
  • 4
    At least one can avoid using the remote head when using `git clone -b master` (or whatever is the name of the existing branch). – eckes Sep 16 '14 at 00:59
  • I've done exactly what you wrote in the last paragraph; There are files in the branch in the bare repo (within gitlab) but the clone seems to be empty. {git branch -a} shows nothing. {git clone -b my-special-branch-name } doesn't seem to work either (remote end hung up). – Ed Randall Mar 10 '15 at 23:15
  • I "fixed" it by copying refs/remotes/my-special-branch-name to refs/heads and editing HEAD to match (in the bare gitlab repo). I could then clone successfully using -b my-special-branch-name. But what is the correct way to configure the bare empty repo after the "init"/"push" cycle so that clone -b does not encounter problem please? – Ed Randall Mar 10 '15 at 23:25
  • 1
    @EdRandall `cd path/to/bare/git/repo; git symbolic-ref HEAD refs/heads/XYZ` where `XYZ` is the default branch name you want to be used if `git clone` is done without the `-b` flag. If you have some another problem, please, ask a new question instead of adding questions as comments. – Mikko Rantalainen Mar 11 '15 at 08:05
  • my "problem" was very easy to fix... I've git push into master branch so I've had to checkout to another branch in order to push, and forgot to checkout back to master. This answer helped me find the problem. Just did git checkout master after git clone in local repository... – Ricardo Gonçalves Jul 27 '18 at 12:07
  • For me worked: when `git branch -a` returns `remotes/origin/master` branch, I run command `git reset --hard origin/master` and `master` was back :) – bedla.czech Aug 18 '20 at 07:07
  • @bedla.czech as I wrote above, just doing `git checkout origin/master` should be enough. No need to `reset` anything. The problem is caused by file called `HEAD` located on the *remote* server containing something else but the default `master`. – Mikko Rantalainen Aug 18 '20 at 09:06
19

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
Marco Bonifazi
  • 623
  • 2
  • 8
  • 10
  • both conditions are possible, master was removed and the HEAD still points to it or HEAD was changed to a branch which was removed afterwards. I guess (since the checkout of master works) the second option is our case. @MarcoBonifazi In that case the "change" would be to replace `broken_branch` with `refs/heads/master`. – eckes Sep 16 '14 at 01:04
  • 3
    is there a "proper" way to set the HEAD branch like this without resorting to editing the files? – Ed Randall Mar 10 '15 at 23:34
  • 1
    @EdRandall `cd path/to/bare/git/repo; git symbolic-ref HEAD refs/heads/XYZ` where `XYZ` is the default branch name you want to be used if `git clone` is done without the `-b` flag, as I said in another comment. – Mikko Rantalainen May 18 '15 at 05:54
15

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.

pal4life
  • 3,210
  • 5
  • 36
  • 57
12

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

Muhammad Shahzad
  • 9,340
  • 21
  • 86
  • 130
6

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

Ng Sek Long
  • 4,233
  • 2
  • 31
  • 38
3

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.

Michu93
  • 5,058
  • 7
  • 47
  • 80
adswebwork
  • 5,245
  • 3
  • 19
  • 9
  • Yes, @Mikko explained it what the reason is. If you want to skip the checkout, you can use the -b option. (But it is better to fix your remote repo in the long run!) – eckes Sep 16 '14 at 01:01
3

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

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

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

Hitesh Sahu
  • 41,955
  • 17
  • 205
  • 154
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
Corrado
  • 21
  • 2
1

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.

Jason Axelson
  • 4,485
  • 4
  • 48
  • 56
  • I guess you meant : "git push -u origin HEAD:HEAD" It did not solve anything for me... – RzR Jul 07 '14 at 13:23
1

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)

Philip Oakley
  • 13,333
  • 9
  • 48
  • 71
1

In my case the repo was empty.

git checkout --orphan master

git add some_file
git commit -m 'init'
git push origin master
László Tóth
  • 483
  • 5
  • 15
0

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.

Samantha
  • 921
  • 9
  • 12
0

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

brendan
  • 290
  • 2
  • 13
0

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.

aeu
  • 141
  • 2
  • 5
0

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

Gayan Weerakutti
  • 11,904
  • 2
  • 71
  • 68