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>...]'
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.
The root of this problem is that one of the references you're looking for doesn't exist.
This could be because:
...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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With