Git 错误: 致命的: 模棱两可的参数‘ HEAD’: 未知的修订或路径不在工作树中

我正在尝试从 Debian初始化一个新的 Git 存储库(实际上是 VirtualBox 上的一个 VM，在 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 #) $]

有什么问题吗？

191795 次浏览
小开

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

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

小开

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 same issue and I solved it by "pod setup" after installing CocoaPods.

小开

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.

小开

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.


提交答案