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

回答1:

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.

回答2:

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 > 

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

回答3:

Not committed yet?

It is a orphan branch if it has no commit.

回答4:

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

git commit -m "initial commit" 

回答5:

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!

回答6:

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.

回答7:

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.

回答8:

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.

回答9:

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. 

文章来源: fatal: bad default revision 'HEAD'