Stefan Beller <sbel...@google.com> writes: > There are 2 dimensions to it: > * (where you are) > if you run git-grep from a sub directory of the repository, then the > "sub-working-tree" > will be searched.
s/the repository/the top level directory of the working tree/, perhaps? >> also, at the bottom of that section, one reads: >> >> <pathspec>... >> If given, limit the search to paths matching at least one >> pattern. Both leading paths match and glob(7) patterns are supported. >> >> For more details about the <pathspec> syntax, see the pathspec >> entry in gitglossary(7). >> >> but, again, what if <pathspec> is *not* given? then what? > > Assume "$pwd/." This is not technically wrong per-se, but I do not think there is any reason to encourage it over just a simple "." dot. >> finally, the first example has the same problem: >> >> git grep 'time_t' -- '*.[ch]' >> Looks for time_t in all tracked .c and .h files in the >> working directory and its subdirectories. >> >> in "the working directory"? >> >> what is the proper terminology to be used here? > > the working directory sounds right, not sure which aspect you want to be > exposed more clearly. "The part of the working tree below and including your current working directory", if you really want to be pedantic ;-). But almost all the examples that show how to work _with_ Git inspecting and manipulating tracked contents assume that your current working directory _is_ inside a working tree of the repository you are working on, so the above is equivalent to "The current working directory" should be clear enough for most readers, I would think.
