Zsh中git log master ^master输出异常原因排查

问题现象 #

执行git log master ^master时，预期应输出空结果（列出master分支提交的同时排除所有master分支提交），但实际却显示master分支的所有提交，效果与直接执行git log master完全一致。该问题仅出现在Zsh环境中，Bash下执行结果符合预期。

已确认master分支与远程仓库同步（git pull返回Already up to date.），使用Git版本为2.50.0，多组测试命令的结果如下：

git log master ^master -> 不符合预期（显示所有master提交）
git log master ^origin/master -> 符合预期（空输出）
git log origin/master ^master -> 不符合预期（显示所有origin/master提交）
git log origin/master ^origin/master -> 符合预期（空输出）

git log master ^refs/heads/master -> 符合预期（空输出）
git log refs/heads/master ^master -> 不符合预期（显示所有master提交）
git log refs/heads/master ^refs/heads/master -> 符合预期（空输出）

git log origin/master ^refs/heads/master -> 符合预期（空输出，证明分支同步）
git log refs/heads/master ^origin/master -> 符合预期（空输出）
git log master..master -> 符合预期（空输出）

根因解析 #

问题源于Zsh的**文件名扩展（Filename Expansion）**机制：

• Zsh默认启用EXTENDED_GLOB扩展通配符功能，其中^是用于反向匹配的特殊字符，作用是匹配当前目录下所有名称不符合指定模式的文件/目录。
• 执行git log master ^master时，Zsh会优先解析^master，尝试匹配当前目录下所有非master命名的文件，再将匹配结果作为参数传递给Git。
• Git原本的^<ref>语法是用于排除指定引用的提交，但Zsh的提前扩展破坏了这一语法，导致Git收到的不是排除分支的指令，而是一堆当前目录的文件名。
• 当Git收到分支名+文件名参数时，会显示该分支下修改这些文件的提交；若当前目录文件较多，几乎所有提交都会被匹配，最终效果就等同于直接执行git log master。

而Bash默认不支持^作为通配符，会直接将^master作为字符串参数传递给Git，Git能正确解析为排除master分支的提交，因此输出空结果。

解决方法 #

有两种方式避免Zsh破坏Git的排除语法：

1. 引用特殊字符：用单引号或双引号包裹^开头的参数，阻止Zsh的文件名扩展：

   git log master '^master'
   

2. 临时禁用扩展通配符：在命令前添加setopt NO_EXTENDED_GLOB，临时关闭EXTENDED_GLOB功能：

   setopt NO_EXTENDED_GLOB; git log master ^master
   

内容的提问来源于stack exchange，提问作者Alexey Nurmukhametov