fatal: bad default revision 'HEAD'

Question

I'm using GIT as my source control system. We have it installed on one of our Linux boxes. Tortoise GIT is my windows client.

This morning I checked in some changes, and tagged the code. I then did a push of my local repository to the remote repository.

When I go to my repository on the unix box and type in git log I get:

fatal: bad default revision 'HEAD'

But when I do a show log using my windows tortoiseGit client the history comes up nicely as per below...

---
SHA-1: f879573ba3d8e62089b8c673257c928779f71692

Initial drop of code

---
master origin/master oms-phase4-v1.0.0
SHA-1: 56176dbe45e6175b18c9f44533828806c63142ab

OMS Phase 4 - Added OMS Cust. Order No. to EDI Purchase Order Header screens

Tag Info

object 56176dbe45e6175b18c9f44533828806c63142ab
type commit
tag oms-phase4-v1.0.0
tagger Richard Riviere <richard.riviere@myer.com.au> 1364338495 +1100

---
SHA-1: 0000000000000000000000000000000000000000

Working dir changes
0 files changed

---

The code has definitely been pushed to the remote repository. I've been able to check by cloning the repository into a different directory.

Does anyone know why I am receiving the fatal: bad default revision 'HEAD'?

p.s. It is a bare repository however I have created other bare repositories which have not had this problem.

Answer 1

This error can show up if you create a new bare repository and you follow random instruction online that push with something that is not the master branch (because of political reason?). In that case "git log --all" will work without errors and you can switch branch using "git checkout master". The issue is that the bare repository does not have the branch master specified which is default in the HEAD file on the remote master git server. Avoid using google as a search engine for finding good git instructions....

Answer 2

just do an initial commit and the error will go away:

git commit -m "initial commit"

Answer 3

I got the same error and couldn't solve it.

Then I noticed 3 extra files in one of my directories.

The files were named:

config, HEAD, description

I deleted the files, and the error didn't appear.

config contained:

[core]
    repositoryformatversion = 0
    filemode = true
    bare = true

HEAD contained:

ref: refs/heads/master

description contained:

Unnamed repository; edit this file 'description' to name the repository.

Answer 4

I don't think this is OP's problem, but if you're like me, you ran into this error while you were trying to play around with git plumbing commands (update-index & cat-file) without ever actually committing anything in the first place. So try committing something (git commit -am 'First commit') and your problem should be solved.

Answer 5

Note: Git 2.6 (Q3/Q4 2015) will finally provide a more meaningful error message.

See commit ce11360 (29 Aug 2015) by Jeff King (peff).
^{(Merged by Junio C Hamano -- gitster -- in commit 699a0f3, 02 Sep 2015)}

log: diagnose empty HEAD more clearly

If you init or clone an empty repository, the initial message from running "git log" is not very friendly:

$ git init
Initialized empty Git repository in /home/peff/foo/.git/
$ git log
fatal: bad default revision 'HEAD'

Let's detect this situation and write a more friendly message:

$ git log
fatal: your current branch 'master' does not have any commits yet

We also detect the case that 'HEAD' points to a broken ref; this should be even less common, but is easy to see.
Note that we do not diagnose all possible cases. We rely on resolve_ref, which means we do not get information about complex cases. E.g., "--default master" would use dwim_ref to find "refs/heads/master", but we notice only that "master" does not exist.
Similarly, a complex sha1 expression like "--default HEAD^2" will not resolve as a ref.

But that's OK. We fall back to a generic error message in those cases, and they are unlikely to be used anyway.
Catching an empty or broken "HEAD" improves the common case, and the other cases are not regressed.

Answer 6

This seems to occur when .git/HEAD refers to a branch which does not exist. I ran into this error in a repo that had nothing in .git/refs/heads. I have no idea how the repo got into that state, I inherited from someone that left the company.

Answer 7

This happens to me when the branch I'm working in gets deleted from the repository, but the workspace I'm in is not updated. (We have a tool that lets you create multiple git "workspaces" from the same repository using simlinks.)

If git branch does not mark any branch as current, try doing

git reset --hard <<some branch>>

I tried a number of approaches until I worked this one out.

Answer 8

Make sure branch "master" exists! It's not just a name apparently.

I got this error after creating a blank bare repo, pushing a branch named "dev" to it, and trying to use git log in the bare repo. Interestingly, git branch knows that dev is the only branch existing (so I think this is a git bug).

Solution: I repeated the procedure, this time having renamed "dev" to "master" on the working repo before pushing to the bare repo. Success!

Answer 9

Your repo is yours, what goes on in it is entirely your business until you push or (allow a) fetch or clone. When you deleted your windows repo -- that folder didn't represent your local repo, it was your actual local repo, you deleted everything done in it that was never pushed, fetched or cloned.

edit: Ah, okay, I think I see what's going on here: you pushed to your linux repo but it's not bare and you never worked in it.

Instead of git log, do git log --all. Or git checkoutsome-branch-name.

Then try cloning the repo locally, on your linux box; I bet it works. What are you using to serve your repo on linux? Try cd'ing into its .git directory and git daemon --base-path=. --export-all, if that just sits there then go to your windows box and try git clone git://your.linux.box.ip, if the daemon complains it can't bind add --port=54345 to the daemon invoke and :54345 to the clone url.

Answer 10

Not committed yet?

It is a orphan branch if it has no commit.