fatal: bad default revision 'HEAD'
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 <firstname.lastname@example.org> 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.
9 Solutions collect form web for “fatal: bad default revision 'HEAD'”
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.
git log, do
git log --all. Or
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.
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.)
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.
Not committed yet?
It is a orphan branch if it has no commit.
just do a initial commit and the error will go away
git commit -m 'initial commit'
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!
Note: Git 2.6 (Q3/Q4 2015) will finally provide a more meaningful error message.
See commit ce11360 (29 Aug 2015) by Jeff King (
(Merged by Junio C Hamano —
gitster — in commit 699a0f3, 02 Sep 2015)
log: diagnose empty
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_refto 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.
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.
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 (
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.
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.
[core] repositoryformatversion = 0 filemode = true bare = true
Unnamed repository; edit this file 'description' to name the repository.