fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree. in a new repository means there is no commit yet, so HEAD points at nothing. Make the first commit, or use a command that does not need HEAD: to unstage a file before the first commit, run git rm --cached <file> or git reset <file>.

The message talks about paths and -- because Git could not read HEAD as a commit and then tried it as a file name. Adding -- changes the outcome per command: in the test git reset HEAD -- app.txt succeeded, while git diff HEAD -- still failed with fatal: bad revision 'HEAD', because there is no commit to compare with.

The error

PS> git reset HEAD secret.txt
fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'

git diff HEAD printed the same three lines, and git rev-parse HEAD the same plus a last line echoing HEAD. All exited with code 128.

Why it happens

After git init, HEAD is a pointer to the branch name main, but that branch does not exist until the first commit creates it. Git calls this an unborn branch. Any command that has to turn the word HEAD into a commit fails, and because a revision that does not resolve might also be meant as a file name, Git reports it as ambiguous. git log is kinder and says it directly: 

PS> git log
fatal: your current branch 'main' does not have any commits yet

The common trigger is the old advice "unstage with git reset HEAD <file>", followed in a fresh repository right after a git add . picked up a file that should not be committed. Scripts that run git diff HEAD or git rev-parse HEAD to read the current commit hit it on a brand new repository too.

The fix

To unstage before the first commit, leave HEAD out:

PS> git reset secret.txt
PS> git status --short
A  app.txt
?? secret.txt

or remove the file from the index explicitly:

PS> git rm --cached secret.txt
rm 'secret.txt'
PS> git status --short
A  app.txt
?? secret.txt

Once a commit exists, the original command works:

PS> git commit -q -m first
PS> git reset HEAD secret.txt
PS> git log --oneline
c90b873 first

Both unstaging commands leave the file on disk and mark it untracked again; add it to .gitignore if it should stay out for good. To see what is staged before the first commit, git diff --cached --stat works without HEAD. In a script, check for an unborn branch before reading HEAD.

How it was reproduced

Git for Windows 2.45.2 on Windows 11, Windows PowerShell 5.1. In a repository created with git init -b main and no commits, git rev-parse HEAD, git diff HEAD and git reset HEAD each failed with exit code 128. In a second fresh repository, after git add ., both git reset secret.txt and git rm --cached secret.txt unstaged the file, and after the first commit git reset HEAD secret.txt succeeded.

Frequently asked

Why does git say ambiguous argument HEAD?
The repository has no commits yet, so HEAD does not point at any commit. Make the first commit, or use a command that does not need HEAD.
How do I unstage a file before the first commit?
Run git reset with just the file name, or git rm --cached with the file name. Both remove it from the index and leave it on disk.
Does adding -- fix ambiguous argument HEAD?
Sometimes. In a repository without commits, git reset HEAD -- file worked in the test, but git diff HEAD -- failed with bad revision 'HEAD'. Only a first commit makes HEAD point at something.

More decoded errors in the Fixes category. If a push from the same new repository fails next, see src refspec main does not match any, which has the same cause.