I\'m trying to initialize a new GIT repo from Debian (actually a VM on Virtualbox, installed and running on Mac OS X) :
[david@server-VM-001:~ $] mkdir test
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. :/current/path). All I needed to do was do my initial commit to my master branch to get this message to go away.
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".
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 had same issue and I solved it by "pod setup" after installing cocoapods.