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

Question

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?

This should not happen... What's the git version? How was it installed? — CharlesB, Sep 04 '12 at 17:40
It looks to me as if you are using some git commands in your shell prompt -- I think the error message is coming from there. — ebneter, Sep 04 '12 at 18:56
Agree it's a bug either with this version of git or the one of your shell prompt, I bet the error disappears on first commit — CharlesB, Sep 04 '12 at 21:28
@davidloubere Not sure, I'd have to see how your git prompt is created. The method I use certainly doesn't give any errors in a new repo. — ebneter, Sep 04 '12 at 22:37
Does the providing of the .bashrc code would help (there's a section called "Git and bash" into it)? I also found a git-completion.bash script... Let me know. — David, Sep 05 '12 at 11:43
This is happening to me because I had an empty repo, into which I made an initial commit, but I wanted to change the default branch name, and tried `git reset HEAD~` — MichaelChirico, Jun 22 '20 at 16:51

score 41 · Answer 1 · answered Oct 14 '12 at 23:16

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

Older versions of git (at least I know this is true of 1.6.4.4) do not use `head` as a synonym for `HEAD`. In my case I'm stuck with this older version of git and was able to get around the problem by referring to `HEAD` in my attempts rather than `head`. — Luke Griffiths, Jan 29 '17 at 00:29

score 37 · Answer 2 · edited Dec 07 '21 at 21:33

37

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

edited Dec 07 '21 at 21:33

Peter Mortensen

30,030
21
100
124

answered Jul 25 '18 at 21:09

J.Adler

1,028
10
16

Great, this worked for me too! I also needed to run `git config user.name "AnyName"` and `git config user.email "any@email.com"` before the command worked. – Jeromy Adofo Sep 29 '20 at 10:54
1

why there is a `.` at the end? – alper Mar 08 '21 at 13:52
1

My mistake, the `.` must be before the last quotation mark. – J.Adler Mar 17 '21 at 22:34

score 8 · Answer 3 · edited Dec 07 '21 at 21:31

8

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.

edited Dec 07 '21 at 21:31

Peter Mortensen

30,030
21
100
124

answered Apr 26 '14 at 17:47

KenStipek

143
1
5

score 5 · Answer 4 · edited Dec 07 '21 at 21:37

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.

score 2 · Answer 5 · edited May 23 '17 at 12:18

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

score 1 · Answer 6 · answered Sep 16 '21 at 20:49

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

This could be because:

the commit you're looking for hasn't happened yet (hence various answers around a new repository not working)
you cloned the repository with a shallow checkout (--depth = 0, bare, or mirrored)
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.

score 1 · Answer 7 · answered Dec 01 '21 at 21:36

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.

score 1 · Answer 8 · answered Mar 08 '22 at 13:48

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.

score -8 · Answer 9 · edited Dec 07 '21 at 21:35

-8

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

edited Dec 07 '21 at 21:35

Peter Mortensen

30,030
21
100
124

answered Aug 22 '19 at 05:54

Jignesh Patel

79
3

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

9 Answers9

Linked

Related