git - 为什么 git grep 中的文件 glob **/*.cs 不显示所有 *.cs 命中？

Question

所以我想在我的项目中找到 NLog 的用途，我使用 git grep 为我这样做，但它发现的情况比我需要的多:

git grep NLog
GETA.Seo.Sitemap/Geta.SEO.Sitemaps.csproj:    <Reference Include="NLog, Version=2.1.0.0, Culture=neutral, PublicKeyToken=5120e14c03d0593c, processorArchitecture=MSIL">
GETA.Seo.Sitemap/Geta.SEO.Sitemaps.csproj:      <HintPath>..\packages\NLog.2.1.0\lib\net45\NLog.dll</HintPath>
GETA.Seo.Sitemap/Services/CloudinaryService.cs:                NLogger.Exception("Could not transform image", exception);
GETA.Seo.Sitemap/Services/CloudinaryService.cs:                NLogger.Warn("Url for cloudinary id was null");
GETA.Seo.Sitemap/Services/CloudinaryService.cs:                NLogger.Warn("Could not locate file object for cloudinary id in EpiServer");
 ....
 etc

当然，它找到了我要找的东西，但我想过滤到仅以 .cs 结尾的文件。所以我尝试这样做:

git grep NLog **/*.cs
Web/Global.asax.cs:            NLogger.Info("Meny application start");

只要一击，我上面的两场比赛都没有列出来。我发现这很奇怪，我可能误解了 git grep 的 globbing 匹配。有没有大佬解惑一下？

Answer 1

(术语注释，对于阅读此答案的任何人:扩展诸如 *.cs 之类的内容称为“globbing”，¹ with *.cs 作为一个“shell glob”。一个“shell”是你的命令行解释器，它可以是sh、bash、zsh、dash, tcsh, 等等。Git 有它自己内置的通配符。扩展的字符称为通配符，它们包括 *、? 和 [。一些 shell 还特别对待 {，这是使用 Git 的 reflog 时的一个问题 名称，如 master@{yesterday} 或 stash@{2}。所有这些都可以引用。)

在这个特殊情况下的问题——它可能会或可能不会发生在其他人身上，这取决于他们使用的是哪个 shell 和他们的环境——是一个未 protected (未引用的)* 经历了 shell globbing。某些 shell，例如 bash，将或至少可以以与 Git 相同的方式扩展 **，这意味着“递归到子目录”。其他人不能，或者取决于设置，不会。²

如果您的 shell 扩展 **/*.cs 以包含名称 Web/Global.asax.cs 但不包含 GETA.Seo.Sitemap/Services/CloudinaryService.cs(因为它在目录的下一级)，然后当 Git 获取名称时，为时已晚:通配符 * 字符消失了。 Git 永远看不到它们，也不能自己做 globbing。

简单的解决方案是通过引用来保护通配符免受 shell 通配符的影响:

git grep '**/*.cs'

(成对的双引号——如在 git grep "**/*.cs" 中一样——在大多数 shell 中也有效，前缀反斜杠在代替引号使用时也有效，如在 git grep\*\*/\*.cs:只需用反斜杠保护每个易受攻击的字符)。对于许多 Git 命令——它对 git grep 没那么重要，除非你正在 grep 旧的提交——最好始终保护所有通配符，以便它们传递给 Git，因为 Git将扩展它们针对当前工作树以外的其他东西。 shell 只看到工作树。³)

虽然它依赖于 shell，但有时通配符会匹配nothing 然后被传递。例如，如果您没有名为 sub 的目录并且您编写了 sub/*，则一些(不是全部)shell 将传递文字文本 sub/* 到你运行的命令。⁴ 在这种情况下，如果命令是 Git 命令，它可以再次进行自己的通配。依赖于此是不明智的，因为一旦有要匹配的内容，shell 就会进行匹配，而不是将原始通配符传递给程序。

---

¹名称“glob”是“global”的缩写，在非常早期的 shell 中，它是由名为 glob 的外部程序完成的。 Early versions of Unix ran on machines with as little as 64 kilobytes of memory ，因此没有太多空间用于花哨的壳内扩展。参见 https://en.wikipedia.org/wiki/Glob_(programming)了解更多。

²在 bash 中，Git 风格的扩展是通过设置变量 globstar 来控制的。

³这甚至可能包括 .git 存储库子目录本身，这通常很糟糕。在 bash 中，这是由变量 dotglob 控制的。

⁴在 bash 中，这是由 failglob 控制的。

请注意，bash 提供了每个可能的 shell 的几乎所有可能的行为。它试图成为一种通用外壳。当然，这意味着它也需要所有这些控制变量，这使得 bash 变得相当大。您永远无法在 64K 非拆分 I&D PDP-11 上运行它。