Why does the file glob **/*.cs in git grep not show me all *.cs hits? -

so wanted find use of nlog in project, , employed git grep me, found few more cases needed:

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 cloudinary id null"); geta.seo.sitemap/services/cloudinaryservice.cs:                nlogger.warn("could not locate file object cloudinary id in episerver");  ....  etc 

granted, found looking for, wanted filter down only files ending in .cs. tried doing this:

git grep nlog **/*.cs web/global.asax.cs:            nlogger.info("meny application start"); 

just 1 hit, , neither of 2 matches had above listed. found peculiar, , have misunderstood globbing matching of git grep. enlighten me?

(terminology note, reading answer: expanding things *.cs called "globbing",¹ *.cs being "shell glob". "shell" command line interpreter, can sh, bash, zsh, dash, tcsh, , on. git has own built-in globbing. expanded characters called wildcards, , include *, ?, , [. shells treat { specially, issue when using git's reflog names master@{yesterday} or stash@{2}. quoting available of these.)

the problem in particular case—it may or may not happen other people, depending on shell use , circumstances—is unprotected (unquoted) * undergoes shell globbing. shells, such bash, will, or @ least can, expand ** same way git does, meaning "recurse subdirectories". others can't, or depending on settings, won't.²

if shell expands **/*.cs include name web/global.asax.cs not include geta.seo.sitemap/services/cloudinaryservice.cs (because that's down 1 more level of directory), time git gets names, it's late: wildcard * characters gone. git never sees them , cannot own globbing.

the simple solution protect wildcard characters shell globbing, quoting them:

git grep '**/*.cs' 

(paired-up double quotes—as in git grep "**/*.cs"—also work in shells, , prefix backslashes work when used instead of quotes, in git grep \*\*/\*.cs: protect each vulnerable character backslash). many git commands—it's not important git grep unless you're grepping older commits—it's idea protect wildcard characters @ times, pass through git, because git expand them against other current work-tree. shell sees work-tree.³)

although it's shell-dependent, wildcard character match nothing , passed through. instance, if have no directory named sub , write sub/*, some—not all—shells pass literal text sub/* command ran.⁴ in case, if command git command, can once again own globbing. it's not wise depend on this, since there is match, shell matching, instead of passing original wildcard character on program.

---

¹the name "glob" shortened "global", , in shells, done external program named glob. early versions of unix ran on machines little 64 kilobytes of memory, there not lot of room fancy in-shell expansion. see https://en.wikipedia.org/wiki/glob_(programming) more.

²in bash, git-style expansion controlled setting variable globstar.

³this might include .git repository subdirectory itself, bad. in bash, controlled variable dotglob.

⁴in bash, controlled failglob.

note bash provides every possible behavior of every possible shell. it's attempting sort of universal shell. of course, means needs these control variables too, makes bash quite big. never able run on 64k non-split-i&d pdp-11.