The ^ character is treated as special in filename expansions in zsh, but only if the EXTENDED_GLOB option is set:
zsh% setopt noEXTENDED_GLOB
zsh% echo HEAD^
HEAD^
zsh% setopt EXTENDED_GLOB
zsh% echo HEAD^
zsh: no matches found: HEAD^
zsh%
Bash doesn't have this feature. (To be precise, bash does have an extended glob feature, enabled by shopt -s extglob, but bash's extended glob syntax doesn't treat the ^ character as special.)
With this feature enabled, ^ is a special character similar to * but with a different meaning. Like *, you can inhibit its special meaning by escaping it, either by enclosing it in single or double quotes or by preceding it with a backslash. Quoting is the simplest solution.
Rather than
git reset HEAD^
try this:
git reset 'HEAD^'
The meaning of the ^ wildcard is not relevant, since all you need to do is avoid using it, but I'll mention it anyway. According to the zsh manual, ^X matches anything except the pattern X. For the case of HEAD^, nothing follows the ^ -- which means that HEAD^ matches HEAD followed by anything other than nothing. That's a roundabout way of saying that HEAD^ matches file names starting with HEAD and followed by some non-empty string. Given files HEAD, HEAD1, and HEAD2, the pattern HEAD^ matches HEAD1 and HEAD2.
A quick workaround to avoid the ^ character is to use git reset head~1 instead of git reset head^.
issue 449 of oh-my-zsh describes this exact behaviour and provides the solution.
The culprit is the option extended_glob on zsh. Presto must be setting it. So when you type HEAD^ zsh tries to create a glob negation expression and fails with an error.
In other words, setopt extended_glob allows us to use ^ to negate globs.
To fix it, you can write this line on your .zshrc:
unsetopt nomatch
With the above line, we are saying to zsh we want that when pattern matching fails, simply use the command "as is".
