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 57 · Answer 1 · edited Dec 07 '21 at 21:33

57

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,738
21
105
131

answered Jul 25 '18 at 21:09

J.Adler

1,303
11
19

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
1

can you explain what makes the error and why this solves the it? – Ooker Jul 09 '22 at 07:43
1

I don't use Windows environments any more and I don't know if the error still occurs nowadays. But in a new repository there are still no references to HEAD and as Jacob Helwing mentioned the commands may be running without enough error checking (at least in Windows environments). When executing the `git-commit` command I pass the `-n` `--no-verify` parameter to avoid calls to the `pre-commit` and `commit-msg`, which makes us fall into the same error as the title of this post, and by using `--allow-empty` allows me just to fix this problem. – J.Adler Jul 10 '22 at 14:33

score 44 · Answer 2 · 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 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,738
21
105
131

answered Apr 26 '14 at 17:47

KenStipek

143
1
5

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

8

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.

edited Dec 07 '21 at 21:37

Peter Mortensen

30,738
21
105
131

answered Jul 22 '21 at 15:20

Akom

1,484
19
25

Similar to my case, except I was using Azure Devops Pipelines which by default uses `--depth=1`. I had to set `fetchDepth: 0` in the checkout step to fetch all commits from the history. – Trapsilo Bumi Apr 13 '23 at 12:54

score 3 · Answer 5 · 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 2 · Answer 6 · 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 2 · 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 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 0 · Answer 9 · answered Apr 08 '23 at 09:30

0

this can happen due to a simple mistake that, you may be working in a different git directory. that is , you must execute the git commands within the clone directory.

answered Apr 08 '23 at 09:30

ashique

935
2
8
26

score -8 · Answer 10 · 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,738
21
105
131

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"

10 Answers10

Linked

Related