GIT-GREP(1)

📦
version 2.56.0 · 25 versions
, in arch rolling

🎀 GIT-GREP(1) 🎀

okay bestie, this is git-grep from the Git manual, and it is literally the main character of "find me the thing in my repo" energy. It's grep but it knows about Git, and honestly? Obsessed. 💅

🌸 NAME 🌸

git-grep — print lines matching a pattern ✨

🦋 SYNOPSIS 🦋

git grep [-a | --text] [-I] [--textconv] [-i | --ignore-case] [-w | --word-regexp]
         [-v | --invert-match] [-h|-H] [--full-name]
         [-E | --extended-regexp] [-G | --basic-regexp]
         [-P | --perl-regexp]
         [-F | --fixed-strings] [-n | --line-number] [--column]
         [-l | --files-with-matches] [-L | --files-without-match]
         [(-O | --open-files-in-pager) [<pager>]]
         [-z | --null]
         [ -o | --only-matching ] [-c | --count] [--all-match] [-q | --quiet]
         [--max-depth <depth>] [--[no-]recursive]
         [--color[=<when>] | --no-color]
         [--break] [--heading] [-p | --show-function]
         [-A <post-context>] [-B <pre-context>] [-C <context>]
         [-W | --function-context]
         [(-m | --max-count) <num>]
         [--threads <num>]
         [-f <file>] [-e] <pattern>
         [--and|--or|--not|(|)|-e <pattern>...]
         [--recurse-submodules] [--parent-basename <basename>]
         [ [--[no-]exclude-standard] [--cached | --untracked | --no-index] | <tree>...]
         [--] [<pathspec>...]

💖 DESCRIPTION 💖

So like — git grep goes looking for the patterns you give it. Where does it look? Pick your vibe:

  • in the tracked files in the work tree,
  • in the blobs registered in the index file, or
  • in the blobs in whatever tree objects</> you hand it.

A "pattern" is actually a list — one or more search expressions — and they're separated by newline characters. and yes, bestie, an empty string as a search expression matches all lines. It's giving "match everything, I'm built different." 😭

✨ OPTIONS ✨

  • --cached — skip the tracked files in the working tree and go search the blobs registered in the index file instead. iykyk.
  • --untracked — on top of the tracked files in the working tree, also search the untracked files. inclusivity icon 💖
  • --no-index — search files in the current directory that Git doesn't manage, or just straight-up ignore that the current directory is managed by Git. This is lowkey similar to running plain grep(1) with its -r option, but with extra perks, like using pathspec patterns to limit paths — check the pathspec entry in gitglossary(7) for the deets.
🚨 careful: this option cannot be used together with --cached or --untracked. Also peep grep.fallbackToNoIndex in CONFIGURATION below.
  • --no-exclude-standard — also search ignored files by not honoring the .gitignore mechanism. Only useful with --untracked. (yes you're being a little chaotic, and that's valid)
  • --exclude-standard — do not pay attention to the ignored files specified via the .gitignore mechanism. Only useful when searching files in the current directory with --no-index.
  • --recurse-submodules — recursively search inside each submodule that is active and checked out in the repo. When you combine it with the <tree> option, the prefix of all submodule output will be the name of the parent project's <tree> object. This one cannot be used together with --untracked, and it has no effect if --no-index is specified. no cap.
  • -a, --text — process binary files as if they were text. 🫶
  • --textconv — honor textconv filter settings.
  • --no-textconv — do not honor textconv filter settings. this is the default.
  • -i, --ignore-case — ignore case differences between the patterns and the files. so Foo and foo are the same person to this flag.
  • -I — don't match the pattern in binary files. 🙈
  • --max-depth <depth> — for each <pathspec> given on the command line, descend at most <depth> levels of directories. A value of -1 means no limit. This option is ignored if <pathspec> contains active wildcards. In other words, if "a*" matches a directory named "a*", then "*" is matched literally, so --max-depth is still effective. the way this actually has rules 😭
  • -r, --recursive — same as --max-depth=-1; this is the default.
  • --no-recursive — same as --max-depth=0.
  • -w, --word-regexp — match the pattern only at a word boundary — either it begins at the beginning of a line, or it's preceded by a non-word character; and it ends at the end of a line or is followed by a non-word character. boundaries, bestie. we love them. ✨
  • -v, --invert-match — select the non-matching lines. contrarian slay.
  • -h, -H — by default, the command shows the filename for each match. -h suppresses this output. -H is there for completeness and does not do anything except that it overrides a -h given earlier on the command line. it's literally just vibes 🧚
  • --full-name — when run from a subdirectory, the command usually outputs paths relative to the current directory. This option forces paths to be output relative to the project top directory. ✨ absolute-adjacent clarity ✨
  • -E, --extended-regexp, -G, --basic-regexp — use POSIX extended/basic regexp for patterns. Default is to use basic regexp.
  • -P, --perl-regexp — use Perl-compatible regular expressions for patterns. heads up: support for these types of regexps is an optional compile-time dependency. If Git wasn't compiled with support for them, providing this option will cause it to die. 💀
  • -F, --fixed-strings — use fixed strings for patterns (don't interpret the pattern as a regex). just literal, no drama.
  • -n, --line-number — prefix the line number to matching lines.
  • --column — prefix the 1-indexed byte-offset of the first match from the start of the matching line.
  • -l, --files-with-matches, --name-only, -L, --files-without-match — instead of showing every matched line, show only the names of files that contain (or do not contain) matches. For better compatibility with git diff, --name-only is a synonym for --files-with-matches.
  • -O[<pager>], --open-files-in-pager[=<pager>] — open the matching files in the pager (not the output of grep, the actual files, mind you). If the pager happens to be "less" or "vi", and the user specified only one pattern, the first file is positioned at the first match automatically. The pager argument is optional; if specified, it must be stuck to the option without a space. If pager is unspecified, the default pager will be used (see core.pager in git-config(1)).
  • -z, --null — use \0 as the delimiter for pathnames in the output, and print them verbatim. Without this option, pathnames with "unusual" characters are quoted as explained for the configuration variable core.quotePath (see git-config(1)).
  • -o, --only-matching — print only the matched (non-empty) parts of a matching line, with each such part on a separate output line. little snippets only, no filler 💅
  • -c, --count — instead of showing every matched line, show the number of lines that match.
  • --color[=<when>] — show colored matches. The value must be always (the default), never, or auto.
  • --no-color — turn off match highlighting, even when the configuration file gives the default to color output. Same as --color=never.
  • --break — print an empty line between matches from different files. breathing room 🦋
  • --heading — show the filename above the matches in that file instead of at the start of each shown line.
  • -p, --show-function — show the preceding line that contains the function name of the match, unless the matching line is a function name itself. The name is determined in the same way as git diff works out patch hunk headers (see Defining a custom hunk-header in gitattributes(5)).
  • -<num>, -C <num>, --context <num> — show <num> leading and trailing lines, and place a line containing -- between contiguous groups of matches.
  • -A <num>, --after-context <num> — show <num> trailing lines, and place a line containing -- between contiguous groups of matches.
  • -B <num>, --before-context <num> — show <num> leading lines, and place a line containing -- between contiguous groups of matches.
  • -W, --function-context — show the surrounding text from the previous line containing a function name up to the one before the next function name, effectively showing the whole function in which the match was found. The function names are determined in the same way as git diff works out patch hunk headers (see Defining a custom hunk-header in gitattributes(5)). the whole function?? ate. 🔥
  • -m <num>, --max-count <num> — limit the amount of matches per file. When using the -v or --invert-match option, the search stops after the specified number of non-matches. A value of -1 will return unlimited results (the default). A value of 0 will exit immediately with a non-zero status. noted. ✍️
  • --threads <num> — number of grep worker threads to use. See NOTES ON THREADS and grep.threads in CONFIGURATION for more info. multitasking queen 👑
  • -f <file> — read patterns from <file>, one per line.

Passing the pattern via <file> allows for providing a search pattern containing a \0.

😭 not all pattern types support patterns containing \0. Git will error out if a given pattern type can't support such a pattern. The --perl-regexp pattern type, when compiled against the PCRE v2 backend, has the widest support for these types of patterns.

In versions of Git before 2.23.0, patterns containing \0 would be silently considered fixed. This was never documented, and there were also odd and undocumented interactions between, e.g., non-ASCII patterns containing \0 and --ignore-case.

In future versions we may learn to support patterns containing \0 for more search backends — until then, we'll die when the pattern type in question doesn't support them.

  • -e — the next parameter is the pattern. This option has to be used for patterns starting with -, and should be used in scripts passing user input to grep. Multiple patterns are combined by or.
  • --and, --or, --not, ( ... ) — specify how multiple patterns are combined using Boolean expressions. --or is the default operator. --and has higher precedence than --or. -e has to be used for all patterns. boolean logic but make it fashion 🎀
  • --all-match — when giving multiple pattern expressions combined with --or, this flag is specified to limit the match to files that have lines to match all of them.
  • -q, --quiet — do not output matched lines; instead, exit with status 0 when there is a match, and with non-zero status when there isn't. silent but deadly 💀
  • <tree>... — instead of searching tracked files in the working tree, search blobs in the given trees.
  • -- — signals the end of options; the rest of the parameters are <pathspec> limiters. the classic "ok we're done with flags" moment.
  • <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). 🌈

🍓 EXAMPLES 🍓

ok so here are the greatest hits, the ones you'll actually use, no cap 💅

git grep 'time_t' -- '*.[ch]'

Lowkey the classic: hunts for time_t in every tracked .c and .h file in your working directory and all the subdirectories below it. Recursive queen behavior ✨

git grep -e '#define' --and \( -e MAX_PATH -e PATH_MAX \)

This one's a lil combo meal 🍟 — it finds a line that has #define and also has either MAX_PATH or PATH_MAX. Two patterns, one --and, chef's kiss.

git grep --all-match -e NODE -e Unexpected

Looks for a line that has NODE or Unexpected, but only in files that have lines matching both. That's the --all-match of it all — file-level vibe check, not line-level 🫶

git grep solution -- :^Documentation

Looks for solution, but excludes files in Documentation. The :^ is literally the "not you bestie" prefix 🙈

🧵 NOTES ON THREADS 🧵

Okay so thread tea ☕ — two things you gotta know:

  • The --threads option (and the grep.threads configuration) gets ignored whenever --open-files-in-pager is in play. Git forces single-threaded execution there, periodt.
  • When you're grepping the object store — that's with --cached, or when you're giving tree objects — running with multiple threads might actually perform slower than single-threaded if --textconv is given and there are too many text conversions. So if you're experiencing low performance in this specific case, it might be desirable to use --threads=1. Yeah. Counterintuitive, but that's the lore 😭

⚙️ CONFIGURATION ⚙️

Heads up bestie: everything below this line in this section is selectively included from the git-config(1) documentation. The content is the same as what's found there. 💖
  • grep.lineNumber — if set to true, enable the -n option by default. Numbers on by default, slay.
  • grep.column — if set to true, enable the --column option by default.
  • grep.patternType — sets the default matching behavior. Using a value of basic, extended, fixed, or perl will enable the --basic-regexp, --extended-regexp, --fixed-strings, or --perl-regexp option accordingly, while the value default will use the grep.extendedRegexp option to choose between basic and extended. So default isn't "no opinion", it's "ask my friend grep.extendedRegexp" 🧚
  • grep.extendedRegexp — if set to true, enable --extended-regexp option by default. But this option is ignored when the grep.patternType option is set to a value other than default. Sorry girl, patternType has main character energy here 👑
  • grep.threads — number of grep worker threads to use. If unset (or set to 0), Git will use as many threads as the number of logical cores available. It just goes full send 🔥
  • grep.fullName — if set to true, enable --full-name option by default.
  • grep.fallbackToNoIndex — if set to true, fall back to git grep --no-index if git grep is executed outside of a git repository. Defaults to false. The safety net is opt-in, bestie 🎀

👑 GIT 👑

Part of the git(1) suite. You already knew that, but she said it anyway 💜

🌈✨ and that's the whole page!! this render was brought to you by Git 2.56.0, dated 2026-09-27 — go forth and grep, bestie, you're gonna eat 💅🎀🦋

📦 where this page comes from