Git error "fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree"

I'm trying to initialize a new Git repository from Debian (actually a VM on VirtualBox, installed and running on Mac OS X):

cd ~
mkdir test
cd test
git init

Initialized empty Git repository in /home/david/test/.git/
fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions

[david@server-VM-001:test  (master #) $]

What's the problem?

As others pointed out, this message is coming from your shell prompt. The problem is that in a freshly created repository HEAD (.git/HEAD) points to a ref that doesn't exist yet.

% git init test
Initialized empty shared Git repository in /Users/jhelwig/tmp/test/.git/
% cd test
% cat .git/HEAD
ref: refs/heads/master
% ls -l .git/refs/heads
total 0
% git rev-parse HEAD
HEAD
fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions

It looks like rev-parse is being used without sufficient error checking before-hand. After the first commit has been created .git/refs/heads looks a bit different and git rev-parse HEAD will no longer fail.

% ls -l .git/refs/heads
total 4
-rw------- 1 jhelwig staff 41 Oct 14 16:07 master
% git rev-parse HEAD
af0f70f8962f8b88eef679a1854991cb0f337f89

In the function that updates the Git information for the rest of my shell prompt (heavily modified version of wunjo prompt theme for ZSH), I have the following to get around this:

zgit_info_update() {
    zgit_info=()

    local gitdir=$(git rev-parse --git-dir 2>/dev/null)
    if [ $? -ne 0 ] || [ -z "$gitdir" ]; then
        return
    fi

    # More code ...
}

I usually use Git on my Linux machine, but at work I have to use Windows. I had the same problem when trying to commit the first commit in a Windows environment.

For those still facing this problem, I was able to resolve it as follows:

git commit --allow-empty -n -m "Initial commit."

I had this issue when having a custom display in my terminal when creating a new Git project (I have my branch display before the pathname, e.g., <branch>:/current/path).

All I needed to do was do my initial commit to my master branch to get this message to go away.

In my case it was the clone depth (which I set to 1 and forgot about it)

Jenkins was running:

git rev-parse 2865c1ce8248de835b5a3fbfcce09e7346d5e3ea^{commit}

(That commit is a few commits behind HEAD.)

When cloning/fetching with --depth=1, I would then get this error when running git rev-parse. When cloning with a bigger number (or no --depth), git rev-parse worked fine.

This may be slightly different from the OP's command, but it may help someone.

Jacob Helwig mentions in his answer that:

> It looks like rev-parse is being used without sufficient error checking before-hand

Commit 62f162f from Jeff King (peff) should improve the robustness of git rev-parse in Git 1.9/2.0 (Q1 2014) (in addition of commit 1418567):

> For cases where we do not match (e.g., "doesnotexist..HEAD"), we would then want to try to treat the argument as a filename.
try_difference() gets this right, and always unmunges in this case.
However, try_parent_shorthand() never unmunges, leading to incorrect error messages, or even incorrect results:

$ git rev-parse foobar^@
foobar
fatal: ambiguous argument 'foobar': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'

The root of this problem is that one of the references you're looking for doesn't exist.

This could be because:

1. the commit you're looking for hasn't happened yet (hence various answers around a new repository not working)
2. you cloned the repository with a shallow checkout (--depth = 0, bare, or mirrored)
3. you checked out a repository excluding tags and/or branches and you're looking for that tag/branch by name

...and probably other reasons I don't know about. In my case, the checkout was full, but excluded tags. Running:

> git fetch --all --tags

cleared it up.

I ran into an issue with this and none of the answers here helped me. The issue turned out to be in a pre-commit check that was using git rev-parse. The script was checking to see if the current branch was master. I changed it to use git branch --show-current in the script instead and the problem went away. It would be helpful if the error message told you what function was running into the issue.

Way 1: Though you see that message you can stage any changes and commit. so

git add .
git commit -m "Initial commit"

after your fisrt commit that message will disapper as you will have default master branch.

way 2: You can start commiting without creating branch as said J.Adler

 git commit --allow-empty -n -m "Initial commit."

So the message disappers. And later you can create your branch.

I had same issue and I solved it by "pod setup" after installing CocoaPods.