2005-09-13 02:39:15 +00:00
|
|
|
git-grep(1)
|
|
|
|
===========
|
|
|
|
|
|
|
|
NAME
|
|
|
|
----
|
2006-03-09 16:24:37 +00:00
|
|
|
git-grep - Print lines matching a pattern
|
2005-09-13 02:39:15 +00:00
|
|
|
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
--------
|
2006-05-08 20:28:49 +00:00
|
|
|
[verse]
|
2013-05-10 15:10:15 +00:00
|
|
|
'git grep' [-a | --text] [-I] [--textconv] [-i | --ignore-case] [-w | --word-regexp]
|
2006-09-16 01:37:01 +00:00
|
|
|
[-v | --invert-match] [-h|-H] [--full-name]
|
2007-04-27 04:58:58 +00:00
|
|
|
[-E | --extended-regexp] [-G | --basic-regexp]
|
2011-05-09 21:52:05 +00:00
|
|
|
[-P | --perl-regexp]
|
2018-06-22 15:49:45 +00:00
|
|
|
[-F | --fixed-strings] [-n | --line-number] [--column]
|
2007-04-27 04:58:58 +00:00
|
|
|
[-l | --files-with-matches] [-L | --files-without-match]
|
2010-06-12 16:39:46 +00:00
|
|
|
[(-O | --open-files-in-pager) [<pager>]]
|
2008-10-01 16:11:15 +00:00
|
|
|
[-z | --null]
|
2018-07-09 20:33:47 +00:00
|
|
|
[ -o | --only-matching ] [-c | --count] [--all-match] [-q | --quiet]
|
2018-10-01 19:15:57 +00:00
|
|
|
[--max-depth <depth>] [--[no-]recursive]
|
Add an optional argument for --color options
Make git-branch, git-show-branch, git-grep, and all the diff-based
programs accept an optional argument <when> for --color. The argument
is a colorbool: "always", "never", or "auto". If no argument is given,
"always" is used; --no-color is an alias for --color=never. This makes
the command-line interface consistent with other GNU tools, such as `ls'
and `grep', and with the git-config color options. Note that, without
an argument, --color and --no-color work exactly as before.
To implement this, two internal changes were made:
1. Allow the first argument of git_config_colorbool() to be NULL,
in which case it returns -1 if the argument isn't "always", "never",
or "auto".
2. Add OPT_COLOR_FLAG(), OPT__COLOR(), and parse_opt_color_flag_cb()
to the option parsing library. The callback uses
git_config_colorbool(), so color.h is now a dependency
of parse-options.c.
Signed-off-by: Mark Lodato <lodatom@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-17 04:55:58 +00:00
|
|
|
[--color[=<when>] | --no-color]
|
2012-03-26 02:41:42 +00:00
|
|
|
[--break] [--heading] [-p | --show-function]
|
2006-05-08 20:28:49 +00:00
|
|
|
[-A <post-context>] [-B <pre-context>] [-C <context>]
|
2012-03-26 02:41:42 +00:00
|
|
|
[-W | --function-context]
|
2022-06-22 19:47:32 +00:00
|
|
|
[(-m | --max-count) <num>]
|
2015-12-15 15:31:39 +00:00
|
|
|
[--threads <num>]
|
2007-04-27 04:58:58 +00:00
|
|
|
[-f <file>] [-e] <pattern>
|
2010-02-26 03:40:12 +00:00
|
|
|
[--and|--or|--not|(|)|-e <pattern>...]
|
2016-12-16 19:03:21 +00:00
|
|
|
[--recurse-submodules] [--parent-basename <basename>]
|
grep docs: describe --no-index further and improve formatting a bit
Improve the description of --no-index, to make it more clear to the users
what this option actually does under the hood, and what's its purpose.
Describe the dependency between --no-index and either of the --cached and
--untracked options, which cannot be used together.
As part of that, shuffle a couple of the options, to make the documentation
flow a bit better, because it makes more sense to describe first the options
that have something in common, and to after that describe an option that does
something differently. In more detail, --cached and --untracked both leave
git-grep(1) in the usual state, in which it treats the directory as a local
git repository, unlike --no-index that makes git-grep(1) treat the directory
not as a git repository.
While there, improve the descriptions of grep worker threads a bit, to give
them better context. Adjust the language a bit, to avoid addressing the
reader directly, which is in general preferred in technical documentation,
because it eliminates the possible element of persuading the user to do
something. In other words, we should be telling the user what our software
can do, instead of telling the user what to do.
Also perform some minor formatting improvements, to make it clear it's the
git commands, command parameters, and configuration option names.
Signed-off-by: Dragan Simic <dsimic@manjaro.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-03-25 20:34:53 +00:00
|
|
|
[ [--[no-]exclude-standard] [--cached | --untracked | --no-index] | <tree>...]
|
2010-02-16 00:25:40 +00:00
|
|
|
[--] [<pathspec>...]
|
2005-09-13 02:39:15 +00:00
|
|
|
|
|
|
|
DESCRIPTION
|
|
|
|
-----------
|
2010-02-16 00:25:40 +00:00
|
|
|
Look for specified patterns in the tracked files in the work tree, blobs
|
2012-05-20 14:33:07 +00:00
|
|
|
registered in the index file, or blobs in given tree objects. Patterns
|
|
|
|
are lists of one or more search expressions separated by newline
|
|
|
|
characters. An empty string as search expression matches all lines.
|
2005-09-13 02:39:15 +00:00
|
|
|
|
|
|
|
|
|
|
|
OPTIONS
|
|
|
|
-------
|
2006-05-08 20:28:49 +00:00
|
|
|
--cached::
|
2010-02-26 03:40:13 +00:00
|
|
|
Instead of searching tracked files in the working tree, search
|
|
|
|
blobs registered in the index file.
|
|
|
|
|
2011-09-27 20:43:12 +00:00
|
|
|
--untracked::
|
|
|
|
In addition to searching in the tracked files in the working
|
|
|
|
tree, search also in untracked files.
|
|
|
|
|
grep docs: describe --no-index further and improve formatting a bit
Improve the description of --no-index, to make it more clear to the users
what this option actually does under the hood, and what's its purpose.
Describe the dependency between --no-index and either of the --cached and
--untracked options, which cannot be used together.
As part of that, shuffle a couple of the options, to make the documentation
flow a bit better, because it makes more sense to describe first the options
that have something in common, and to after that describe an option that does
something differently. In more detail, --cached and --untracked both leave
git-grep(1) in the usual state, in which it treats the directory as a local
git repository, unlike --no-index that makes git-grep(1) treat the directory
not as a git repository.
While there, improve the descriptions of grep worker threads a bit, to give
them better context. Adjust the language a bit, to avoid addressing the
reader directly, which is in general preferred in technical documentation,
because it eliminates the possible element of persuading the user to do
something. In other words, we should be telling the user what our software
can do, instead of telling the user what to do.
Also perform some minor formatting improvements, to make it clear it's the
git commands, command parameters, and configuration option names.
Signed-off-by: Dragan Simic <dsimic@manjaro.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-03-25 20:34:53 +00:00
|
|
|
--no-index::
|
|
|
|
Search files in the current directory that is not managed by Git,
|
|
|
|
or by ignoring that the current directory is managed by Git. This
|
|
|
|
is rather similar to running the regular `grep(1)` utility with its
|
|
|
|
`-r` option specified, but with some additional benefits, such as
|
|
|
|
using pathspec patterns to limit paths; see the 'pathspec' entry
|
|
|
|
in linkgit:gitglossary[7] for more information.
|
|
|
|
+
|
|
|
|
This option cannot be used together with `--cached` or `--untracked`.
|
|
|
|
See also `grep.fallbackToNoIndex` in 'CONFIGURATION' below.
|
|
|
|
|
2011-09-27 20:43:12 +00:00
|
|
|
--no-exclude-standard::
|
|
|
|
Also search in ignored files by not honoring the `.gitignore`
|
|
|
|
mechanism. Only useful with `--untracked`.
|
|
|
|
|
|
|
|
--exclude-standard::
|
2019-03-06 06:30:18 +00:00
|
|
|
Do not pay attention to ignored files specified via the `.gitignore`
|
2011-09-27 20:43:12 +00:00
|
|
|
mechanism. Only useful when searching files in the current directory
|
|
|
|
with `--no-index`.
|
2006-05-08 20:28:49 +00:00
|
|
|
|
2016-12-16 19:03:20 +00:00
|
|
|
--recurse-submodules::
|
doc: --recurse-submodules mostly applies to active submodules
The documentation refers to "initialized" or "populated" submodules,
to explain which submodules are affected by '--recurse-submodules', but
the real terminology here is 'active' submodules. Update the
documentation accordingly.
Some terminology:
- Active is defined in gitsubmodules(7), it only involves the
configuration variables 'submodule.active', 'submodule.<name>.active'
and 'submodule.<name>.url'. The function
submodule.c::is_submodule_active checks that a submodule is active.
- Populated means that the submodule's working tree is present (and the
gitfile correctly points to the submodule repository), i.e. either the
superproject was cloned with ` --recurse-submodules`, or the user ran
`git submodule update --init`, or `git submodule init [<path>]` and
`git submodule update [<path>]` separately which populated the
submodule working tree. This does not involve the 3 configuration
variables above.
- Initialized (at least in the context of the man pages involved in this
patch) means both "populated" and "active" as defined above, i.e. what
`git submodule update --init` does.
The --recurse-submodules option mostly affects active submodules. An
exception is `git fetch` where the option affects populated submodules.
As a consequence, in `git pull --recurse-submodules` the fetch affects
populated submodules, but the resulting working tree update only affects
active submodules.
In the documentation of `git-pull`, let's distinguish between the
fetching part which affects populated submodules, and the updating of
worktrees, which only affects active submodules.
Signed-off-by: Damien Robert <damien.olivier.robert+git@gmail.com>
Helped-by: Philippe Blain <levraiphilippeblain@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-06 13:57:09 +00:00
|
|
|
Recursively search in each submodule that is active and
|
2016-12-16 19:03:21 +00:00
|
|
|
checked out in the repository. When used in combination with the
|
2024-03-25 20:34:52 +00:00
|
|
|
_<tree>_ option the prefix of all submodule output will be the name of
|
|
|
|
the parent project's _<tree>_ object. This option cannot be used together
|
|
|
|
with `--untracked`, and it has no effect if `--no-index` is specified.
|
2016-12-16 19:03:21 +00:00
|
|
|
|
2008-06-08 01:36:09 +00:00
|
|
|
-a::
|
|
|
|
--text::
|
2006-05-08 20:28:49 +00:00
|
|
|
Process binary files as if they were text.
|
|
|
|
|
2013-05-10 15:10:15 +00:00
|
|
|
--textconv::
|
|
|
|
Honor textconv filter settings.
|
|
|
|
|
|
|
|
--no-textconv::
|
|
|
|
Do not honor textconv filter settings.
|
|
|
|
This is the default.
|
|
|
|
|
2008-06-08 01:36:09 +00:00
|
|
|
-i::
|
|
|
|
--ignore-case::
|
2006-05-08 20:28:49 +00:00
|
|
|
Ignore case differences between the patterns and the
|
|
|
|
files.
|
|
|
|
|
2007-04-27 04:58:58 +00:00
|
|
|
-I::
|
|
|
|
Don't match the pattern in binary files.
|
|
|
|
|
grep: Add --max-depth option.
It is useful to grep directories non-recursively, e.g. when one wants to
look for all files in the toplevel directory, but not in any subdirectory,
or in Documentation/, but not in Documentation/technical/.
This patch adds support for --max-depth <depth> option to git-grep. If it is
given, git-grep descends at most <depth> levels of directories below paths
specified on the command line.
Note that if path specified on command line contains wildcards, this option
makes no sense, e.g.
$ git grep -l --max-depth 0 GNU -- 'contrib/*'
(note the quotes) will search all files in contrib/, even in
subdirectories, because '*' matches all files.
Documentation updates, bash-completion and simple test cases are also
provided.
Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-22 17:52:15 +00:00
|
|
|
--max-depth <depth>::
|
2010-02-16 00:25:40 +00:00
|
|
|
For each <pathspec> given on command line, descend at most <depth>
|
2018-10-01 19:15:57 +00:00
|
|
|
levels of directories. A value of -1 means no limit.
|
2012-01-14 09:23:22 +00:00
|
|
|
This option is ignored if <pathspec> contains active wildcards.
|
|
|
|
In other words if "a*" matches a directory named "a*",
|
|
|
|
"*" is matched literally so --max-depth is still effective.
|
grep: Add --max-depth option.
It is useful to grep directories non-recursively, e.g. when one wants to
look for all files in the toplevel directory, but not in any subdirectory,
or in Documentation/, but not in Documentation/technical/.
This patch adds support for --max-depth <depth> option to git-grep. If it is
given, git-grep descends at most <depth> levels of directories below paths
specified on the command line.
Note that if path specified on command line contains wildcards, this option
makes no sense, e.g.
$ git grep -l --max-depth 0 GNU -- 'contrib/*'
(note the quotes) will search all files in contrib/, even in
subdirectories, because '*' matches all files.
Documentation updates, bash-completion and simple test cases are also
provided.
Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-22 17:52:15 +00:00
|
|
|
|
2018-10-01 19:15:57 +00:00
|
|
|
-r::
|
|
|
|
--recursive::
|
|
|
|
Same as `--max-depth=-1`; this is the default.
|
|
|
|
|
|
|
|
--no-recursive::
|
|
|
|
Same as `--max-depth=0`.
|
|
|
|
|
2008-06-08 01:36:09 +00:00
|
|
|
-w::
|
|
|
|
--word-regexp::
|
2006-05-08 20:28:49 +00:00
|
|
|
Match the pattern only at word boundary (either begin at the
|
|
|
|
beginning of a line, or preceded by a non-word character; end at
|
|
|
|
the end of a line or followed by a non-word character).
|
|
|
|
|
2008-06-08 01:36:09 +00:00
|
|
|
-v::
|
|
|
|
--invert-match::
|
2006-05-08 20:28:49 +00:00
|
|
|
Select non-matching lines.
|
|
|
|
|
2008-06-08 01:36:09 +00:00
|
|
|
-h::
|
|
|
|
-H::
|
2006-09-16 01:37:01 +00:00
|
|
|
By default, the command shows the filename for each
|
|
|
|
match. `-h` option is used to suppress this output.
|
|
|
|
`-H` is there for completeness and does not do anything
|
|
|
|
except it overrides `-h` given earlier on the command
|
|
|
|
line.
|
|
|
|
|
2006-08-11 07:44:42 +00:00
|
|
|
--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.
|
|
|
|
|
2008-06-08 01:36:09 +00:00
|
|
|
-E::
|
|
|
|
--extended-regexp::
|
|
|
|
-G::
|
|
|
|
--basic-regexp::
|
2006-05-08 20:28:49 +00:00
|
|
|
Use POSIX extended/basic regexp for patterns. Default
|
|
|
|
is to use basic regexp.
|
2006-01-20 23:00:12 +00:00
|
|
|
|
2011-05-09 21:52:05 +00:00
|
|
|
-P::
|
|
|
|
--perl-regexp::
|
2017-05-20 21:42:05 +00:00
|
|
|
Use Perl-compatible regular expressions for patterns.
|
|
|
|
+
|
|
|
|
Support for these types of regular expressions is an optional
|
|
|
|
compile-time dependency. If Git wasn't compiled with support for them
|
|
|
|
providing this option will cause it to die.
|
2011-05-09 21:52:05 +00:00
|
|
|
|
2008-06-08 01:36:09 +00:00
|
|
|
-F::
|
|
|
|
--fixed-strings::
|
2007-04-27 04:58:58 +00:00
|
|
|
Use fixed strings for patterns (don't interpret pattern
|
|
|
|
as a regex).
|
|
|
|
|
2006-05-08 20:28:49 +00:00
|
|
|
-n::
|
2011-03-28 18:11:55 +00:00
|
|
|
--line-number::
|
2006-05-08 20:28:49 +00:00
|
|
|
Prefix the line number to matching lines.
|
2005-09-13 02:39:15 +00:00
|
|
|
|
2018-06-22 15:49:45 +00:00
|
|
|
--column::
|
|
|
|
Prefix the 1-indexed byte-offset of the first match from the start of the
|
|
|
|
matching line.
|
|
|
|
|
2008-06-08 01:36:09 +00:00
|
|
|
-l::
|
|
|
|
--files-with-matches::
|
|
|
|
--name-only::
|
|
|
|
-L::
|
|
|
|
--files-without-match::
|
2006-05-08 20:28:49 +00:00
|
|
|
Instead of showing every matched line, show only the
|
|
|
|
names of files that contain (or do not contain) matches.
|
2010-02-26 03:40:11 +00:00
|
|
|
For better compatibility with 'git diff', `--name-only` is a
|
|
|
|
synonym for `--files-with-matches`.
|
2005-09-13 02:39:15 +00:00
|
|
|
|
2015-09-19 07:47:49 +00:00
|
|
|
-O[<pager>]::
|
|
|
|
--open-files-in-pager[=<pager>]::
|
2010-06-12 16:36:51 +00:00
|
|
|
Open the matching files in the pager (not the output of 'grep').
|
|
|
|
If the pager happens to be "less" or "vi", and the user
|
|
|
|
specified only one pattern, the first file is positioned at
|
2015-09-19 07:47:50 +00:00
|
|
|
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 linkgit:git-config[1]).
|
2010-06-12 16:36:51 +00:00
|
|
|
|
2008-10-01 16:11:15 +00:00
|
|
|
-z::
|
|
|
|
--null::
|
2020-04-19 06:33:24 +00:00
|
|
|
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
|
2024-03-25 20:34:52 +00:00
|
|
|
variable `core.quotePath` (see linkgit:git-config[1]).
|
2008-10-01 16:11:15 +00:00
|
|
|
|
2018-07-09 20:33:47 +00:00
|
|
|
-o::
|
|
|
|
--only-matching::
|
|
|
|
Print only the matched (non-empty) parts of a matching line, with each such
|
|
|
|
part on a separate output line.
|
|
|
|
|
2008-06-08 01:36:09 +00:00
|
|
|
-c::
|
|
|
|
--count::
|
2006-05-08 20:28:49 +00:00
|
|
|
Instead of showing every matched line, show the number of
|
|
|
|
lines that match.
|
|
|
|
|
Add an optional argument for --color options
Make git-branch, git-show-branch, git-grep, and all the diff-based
programs accept an optional argument <when> for --color. The argument
is a colorbool: "always", "never", or "auto". If no argument is given,
"always" is used; --no-color is an alias for --color=never. This makes
the command-line interface consistent with other GNU tools, such as `ls'
and `grep', and with the git-config color options. Note that, without
an argument, --color and --no-color work exactly as before.
To implement this, two internal changes were made:
1. Allow the first argument of git_config_colorbool() to be NULL,
in which case it returns -1 if the argument isn't "always", "never",
or "auto".
2. Add OPT_COLOR_FLAG(), OPT__COLOR(), and parse_opt_color_flag_cb()
to the option parsing library. The callback uses
git_config_colorbool(), so color.h is now a dependency
of parse-options.c.
Signed-off-by: Mark Lodato <lodatom@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-17 04:55:58 +00:00
|
|
|
--color[=<when>]::
|
2009-03-07 12:32:32 +00:00
|
|
|
Show colored matches.
|
Add an optional argument for --color options
Make git-branch, git-show-branch, git-grep, and all the diff-based
programs accept an optional argument <when> for --color. The argument
is a colorbool: "always", "never", or "auto". If no argument is given,
"always" is used; --no-color is an alias for --color=never. This makes
the command-line interface consistent with other GNU tools, such as `ls'
and `grep', and with the git-config color options. Note that, without
an argument, --color and --no-color work exactly as before.
To implement this, two internal changes were made:
1. Allow the first argument of git_config_colorbool() to be NULL,
in which case it returns -1 if the argument isn't "always", "never",
or "auto".
2. Add OPT_COLOR_FLAG(), OPT__COLOR(), and parse_opt_color_flag_cb()
to the option parsing library. The callback uses
git_config_colorbool(), so color.h is now a dependency
of parse-options.c.
Signed-off-by: Mark Lodato <lodatom@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-17 04:55:58 +00:00
|
|
|
The value must be always (the default), never, or auto.
|
2009-03-07 12:32:32 +00:00
|
|
|
|
|
|
|
--no-color::
|
|
|
|
Turn off match highlighting, even when the configuration file
|
|
|
|
gives the default to color output.
|
Add an optional argument for --color options
Make git-branch, git-show-branch, git-grep, and all the diff-based
programs accept an optional argument <when> for --color. The argument
is a colorbool: "always", "never", or "auto". If no argument is given,
"always" is used; --no-color is an alias for --color=never. This makes
the command-line interface consistent with other GNU tools, such as `ls'
and `grep', and with the git-config color options. Note that, without
an argument, --color and --no-color work exactly as before.
To implement this, two internal changes were made:
1. Allow the first argument of git_config_colorbool() to be NULL,
in which case it returns -1 if the argument isn't "always", "never",
or "auto".
2. Add OPT_COLOR_FLAG(), OPT__COLOR(), and parse_opt_color_flag_cb()
to the option parsing library. The callback uses
git_config_colorbool(), so color.h is now a dependency
of parse-options.c.
Signed-off-by: Mark Lodato <lodatom@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-17 04:55:58 +00:00
|
|
|
Same as `--color=never`.
|
2009-03-07 12:32:32 +00:00
|
|
|
|
2011-06-05 15:24:25 +00:00
|
|
|
--break::
|
|
|
|
Print an empty line between matches from different files.
|
|
|
|
|
2011-06-05 15:24:36 +00:00
|
|
|
--heading::
|
|
|
|
Show the filename above the matches in that file instead of
|
|
|
|
at the start of each shown line.
|
|
|
|
|
2009-07-01 22:06:34 +00:00
|
|
|
-p::
|
|
|
|
--show-function::
|
|
|
|
Show the preceding line that contains the function name of
|
|
|
|
the match, unless the matching line is a function name itself.
|
2020-11-01 17:28:43 +00:00
|
|
|
The name is determined in the same way as `git diff` works out
|
2009-07-01 22:07:24 +00:00
|
|
|
patch hunk headers (see 'Defining a custom hunk-header' in
|
|
|
|
linkgit:gitattributes[5]).
|
2009-07-01 22:06:34 +00:00
|
|
|
|
2011-08-01 17:22:52 +00:00
|
|
|
-<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.
|
|
|
|
|
2011-08-01 17:20:53 +00:00
|
|
|
-W::
|
2011-08-01 17:22:52 +00:00
|
|
|
--function-context::
|
2011-08-01 17:20:53 +00:00
|
|
|
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
|
2020-11-01 17:28:43 +00:00
|
|
|
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 linkgit:gitattributes[5]).
|
2011-08-01 17:20:53 +00:00
|
|
|
|
2022-06-22 19:47:32 +00:00
|
|
|
-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.
|
|
|
|
|
2015-12-15 15:31:39 +00:00
|
|
|
--threads <num>::
|
grep docs: describe --no-index further and improve formatting a bit
Improve the description of --no-index, to make it more clear to the users
what this option actually does under the hood, and what's its purpose.
Describe the dependency between --no-index and either of the --cached and
--untracked options, which cannot be used together.
As part of that, shuffle a couple of the options, to make the documentation
flow a bit better, because it makes more sense to describe first the options
that have something in common, and to after that describe an option that does
something differently. In more detail, --cached and --untracked both leave
git-grep(1) in the usual state, in which it treats the directory as a local
git repository, unlike --no-index that makes git-grep(1) treat the directory
not as a git repository.
While there, improve the descriptions of grep worker threads a bit, to give
them better context. Adjust the language a bit, to avoid addressing the
reader directly, which is in general preferred in technical documentation,
because it eliminates the possible element of persuading the user to do
something. In other words, we should be telling the user what our software
can do, instead of telling the user what to do.
Also perform some minor formatting improvements, to make it clear it's the
git commands, command parameters, and configuration option names.
Signed-off-by: Dragan Simic <dsimic@manjaro.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-03-25 20:34:53 +00:00
|
|
|
Number of `grep` worker threads to use. See 'NOTES ON THREADS'
|
|
|
|
and `grep.threads` in 'CONFIGURATION' for more information.
|
2015-12-15 15:31:39 +00:00
|
|
|
|
2006-05-08 20:28:49 +00:00
|
|
|
-f <file>::
|
|
|
|
Read patterns from <file>, one per line.
|
2019-07-01 21:20:57 +00:00
|
|
|
+
|
|
|
|
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, 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.
|
2006-05-08 20:28:49 +00:00
|
|
|
|
2006-06-25 16:07:15 +00:00
|
|
|
-e::
|
|
|
|
The next parameter is the pattern. This option has to be
|
2010-02-26 03:40:11 +00:00
|
|
|
used for patterns starting with `-` and should be used in
|
2006-08-02 22:04:56 +00:00
|
|
|
scripts passing user input to grep. Multiple patterns are
|
|
|
|
combined by 'or'.
|
|
|
|
|
2008-06-08 01:36:09 +00:00
|
|
|
--and::
|
|
|
|
--or::
|
|
|
|
--not::
|
|
|
|
( ... )::
|
2007-01-17 15:32:41 +00:00
|
|
|
Specify how multiple patterns are combined using Boolean
|
2006-08-02 22:04:56 +00:00
|
|
|
expressions. `--or` is the default operator. `--and` has
|
|
|
|
higher precedence than `--or`. `-e` has to be used for all
|
|
|
|
patterns.
|
2006-06-25 16:07:15 +00:00
|
|
|
|
2006-09-28 00:50:52 +00:00
|
|
|
--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.
|
|
|
|
|
2010-01-28 20:33:42 +00:00
|
|
|
-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.
|
|
|
|
|
2010-02-26 03:40:11 +00:00
|
|
|
<tree>...::
|
2010-02-26 03:40:13 +00:00
|
|
|
Instead of searching tracked files in the working tree, search
|
|
|
|
blobs in the given trees.
|
2006-05-08 20:28:49 +00:00
|
|
|
|
2006-08-02 22:04:56 +00:00
|
|
|
\--::
|
2006-05-08 20:28:49 +00:00
|
|
|
Signals the end of options; the rest of the parameters
|
2010-02-16 00:25:40 +00:00
|
|
|
are <pathspec> limiters.
|
2005-09-13 02:39:15 +00:00
|
|
|
|
2010-02-16 00:25:40 +00:00
|
|
|
<pathspec>...::
|
|
|
|
If given, limit the search to paths matching at least one pattern.
|
|
|
|
Both leading paths match and glob(7) patterns are supported.
|
2017-09-25 08:09:00 +00:00
|
|
|
+
|
|
|
|
For more details about the <pathspec> syntax, see the 'pathspec' entry
|
|
|
|
in linkgit:gitglossary[7].
|
2005-09-13 02:39:15 +00:00
|
|
|
|
2018-04-30 15:35:33 +00:00
|
|
|
EXAMPLES
|
2010-02-26 03:40:10 +00:00
|
|
|
--------
|
2006-08-02 22:04:56 +00:00
|
|
|
|
docs: stop using asciidoc no-inline-literal
In asciidoc 7, backticks like `foo` produced a typographic
effect, but did not otherwise affect the syntax. In asciidoc
8, backticks introduce an "inline literal" inside which markup
is not interpreted. To keep compatibility with existing
documents, asciidoc 8 has a "no-inline-literal" attribute to
keep the old behavior. We enabled this so that the
documentation could be built on either version.
It has been several years now, and asciidoc 7 is no longer
in wide use. We can now decide whether or not we want
inline literals on their own merits, which are:
1. The source is much easier to read when the literal
contains punctuation. You can use `master~1` instead
of `master{tilde}1`.
2. They are less error-prone. Because of point (1), we
tend to make mistakes and forget the extra layer of
quoting.
This patch removes the no-inline-literal attribute from the
Makefile and converts every use of backticks in the
documentation to an inline literal (they must be cleaned up,
or the example above would literally show "{tilde}" in the
output).
Problematic sites were found by grepping for '`.*[{\\]' and
examined and fixed manually. The results were then verified
by comparing the output of "html2text" on the set of
generated html pages. Doing so revealed that in addition to
making the source more readable, this patch fixes several
formatting bugs:
- HTML rendering used the ellipsis character instead of
literal "..." in code examples (like "git log A...B")
- some code examples used the right-arrow character
instead of '->' because they failed to quote
- api-config.txt did not quote tilde, and the resulting
HTML contained a bogus snippet like:
<tt><sub></tt> foo <tt></sub>bar</tt>
which caused some parsers to choke and omit whole
sections of the page.
- git-commit.txt confused ``foo`` (backticks inside a
literal) with ``foo'' (matched double-quotes)
- mentions of `A U Thor <author@example.com>` used to
erroneously auto-generate a mailto footnote for
author@example.com
- the description of --word-diff=plain incorrectly showed
the output as "[-removed-] and {added}", not "{+added+}".
- using "prime" notation like:
commit `C` and its replacement `C'`
confused asciidoc into thinking that everything between
the first backtick and the final apostrophe were meant
to be inside matched quotes
- asciidoc got confused by the escaping of some of our
asterisks. In particular,
`credential.\*` and `credential.<url>.\*`
properly escaped the asterisk in the first case, but
literally passed through the backslash in the second
case.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-26 08:51:57 +00:00
|
|
|
`git grep 'time_t' -- '*.[ch]'`::
|
2010-02-16 00:25:40 +00:00
|
|
|
Looks for `time_t` in all tracked .c and .h files in the working
|
|
|
|
directory and its subdirectories.
|
|
|
|
|
docs: stop using asciidoc no-inline-literal
In asciidoc 7, backticks like `foo` produced a typographic
effect, but did not otherwise affect the syntax. In asciidoc
8, backticks introduce an "inline literal" inside which markup
is not interpreted. To keep compatibility with existing
documents, asciidoc 8 has a "no-inline-literal" attribute to
keep the old behavior. We enabled this so that the
documentation could be built on either version.
It has been several years now, and asciidoc 7 is no longer
in wide use. We can now decide whether or not we want
inline literals on their own merits, which are:
1. The source is much easier to read when the literal
contains punctuation. You can use `master~1` instead
of `master{tilde}1`.
2. They are less error-prone. Because of point (1), we
tend to make mistakes and forget the extra layer of
quoting.
This patch removes the no-inline-literal attribute from the
Makefile and converts every use of backticks in the
documentation to an inline literal (they must be cleaned up,
or the example above would literally show "{tilde}" in the
output).
Problematic sites were found by grepping for '`.*[{\\]' and
examined and fixed manually. The results were then verified
by comparing the output of "html2text" on the set of
generated html pages. Doing so revealed that in addition to
making the source more readable, this patch fixes several
formatting bugs:
- HTML rendering used the ellipsis character instead of
literal "..." in code examples (like "git log A...B")
- some code examples used the right-arrow character
instead of '->' because they failed to quote
- api-config.txt did not quote tilde, and the resulting
HTML contained a bogus snippet like:
<tt><sub></tt> foo <tt></sub>bar</tt>
which caused some parsers to choke and omit whole
sections of the page.
- git-commit.txt confused ``foo`` (backticks inside a
literal) with ``foo'' (matched double-quotes)
- mentions of `A U Thor <author@example.com>` used to
erroneously auto-generate a mailto footnote for
author@example.com
- the description of --word-diff=plain incorrectly showed
the output as "[-removed-] and {added}", not "{+added+}".
- using "prime" notation like:
commit `C` and its replacement `C'`
confused asciidoc into thinking that everything between
the first backtick and the final apostrophe were meant
to be inside matched quotes
- asciidoc got confused by the escaping of some of our
asterisks. In particular,
`credential.\*` and `credential.<url>.\*`
properly escaped the asterisk in the first case, but
literally passed through the backslash in the second
case.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-26 08:51:57 +00:00
|
|
|
`git grep -e '#define' --and \( -e MAX_PATH -e PATH_MAX \)`::
|
2006-08-02 22:04:56 +00:00
|
|
|
Looks for a line that has `#define` and either `MAX_PATH` or
|
|
|
|
`PATH_MAX`.
|
|
|
|
|
docs: put listed example commands in backticks
Many examples of git command invocation are given in asciidoc listing
blocks, which makes them monospaced and avoids further interpretation of
special characters. Some manpages make a list of examples, like:
git foo::
Run git foo.
git foo -q::
Use the "-q" option.
to quickly show many variants. However, they can sometimes be hard to
read, because they are shown in a proportional-width font (so, for
example, seeing the difference between "-- foo" and "--foo" can be
difficult).
This patch puts all such examples into backticks, which gives the
equivalent formatting to a listing block (i.e., monospaced and without
character interpretation).
As a bonus, this also fixes an example in the git-push manpage, in which
"git push origin :::" was accidentally considered a newly-indented list,
and not a list item with "git push origin :" in it.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04 02:13:29 +00:00
|
|
|
`git grep --all-match -e NODE -e Unexpected`::
|
2006-09-28 00:50:52 +00:00
|
|
|
Looks for a line that has `NODE` or `Unexpected` in
|
|
|
|
files that have lines that match both.
|
|
|
|
|
2017-09-25 08:09:00 +00:00
|
|
|
`git grep solution -- :^Documentation`::
|
|
|
|
Looks for `solution`, excluding files in `Documentation`.
|
|
|
|
|
grep: re-enable threads in non-worktree case
They were disabled at 53b8d93 ("grep: disable threading in non-worktree
case", 12-12-2011), due to observable performance drops (to the point
that using a single thread would be faster than multiple threads). But
now that zlib inflation can be performed in parallel we can regain the
speedup, so let's re-enable threads in non-worktree grep.
Grepping 'abcd[02]' ("Regex 1") and '(static|extern) (int|double) \*'
("Regex 2") at chromium's repository[1] I got:
Threads | Regex 1 | Regex 2
---------|------------|-----------
1 | 17.2920s | 20.9624s
2 | 9.6512s | 11.3184s
4 | 6.7723s | 7.6268s
8** | 6.2886s | 6.9843s
These are all means of 30 executions after 2 warmup runs. All tests were
executed on an i7-7700HQ (quad-core w/ hyper-threading), 16GB of RAM and
SSD, running Manjaro Linux. But to make sure the optimization also
performs well on HDD, the tests were repeated on another machine with an
i5-4210U (dual-core w/ hyper-threading), 8GB of RAM and HDD (SATA III,
5400 rpm), also running Manjaro Linux:
Threads | Regex 1 | Regex 2
---------|------------|-----------
1 | 18.4035s | 22.5368s
2 | 12.5063s | 14.6409s
4** | 10.9136s | 12.7106s
** Note that in these cases we relied on hyper-threading, and that's
probably why we don't see a big difference in time.
Unfortunately, multithreaded git-grep might be slow in the non-worktree
case when --textconv is used and there're too many text conversions.
Probably the reason for this is that the object read lock is used to
protect fill_textconv() and therefore there is a mutual exclusion
between textconv execution and object reading. Because both are
time-consuming operations, not being able to perform them in parallel
can cause performance drops. To inform the users about this (and other
threading details), let's also add a "NOTES ON THREADS" section to
Documentation/git-grep.txt.
[1]: chromium’s repo at commit 03ae96f (“Add filters testing at DSF=2”,
04-06-2019), after a 'git gc' execution.
Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-16 02:39:58 +00:00
|
|
|
NOTES ON THREADS
|
|
|
|
----------------
|
|
|
|
|
2024-03-25 20:34:52 +00:00
|
|
|
The `--threads` option (and the `grep.threads` configuration) will be ignored when
|
grep: re-enable threads in non-worktree case
They were disabled at 53b8d93 ("grep: disable threading in non-worktree
case", 12-12-2011), due to observable performance drops (to the point
that using a single thread would be faster than multiple threads). But
now that zlib inflation can be performed in parallel we can regain the
speedup, so let's re-enable threads in non-worktree grep.
Grepping 'abcd[02]' ("Regex 1") and '(static|extern) (int|double) \*'
("Regex 2") at chromium's repository[1] I got:
Threads | Regex 1 | Regex 2
---------|------------|-----------
1 | 17.2920s | 20.9624s
2 | 9.6512s | 11.3184s
4 | 6.7723s | 7.6268s
8** | 6.2886s | 6.9843s
These are all means of 30 executions after 2 warmup runs. All tests were
executed on an i7-7700HQ (quad-core w/ hyper-threading), 16GB of RAM and
SSD, running Manjaro Linux. But to make sure the optimization also
performs well on HDD, the tests were repeated on another machine with an
i5-4210U (dual-core w/ hyper-threading), 8GB of RAM and HDD (SATA III,
5400 rpm), also running Manjaro Linux:
Threads | Regex 1 | Regex 2
---------|------------|-----------
1 | 18.4035s | 22.5368s
2 | 12.5063s | 14.6409s
4** | 10.9136s | 12.7106s
** Note that in these cases we relied on hyper-threading, and that's
probably why we don't see a big difference in time.
Unfortunately, multithreaded git-grep might be slow in the non-worktree
case when --textconv is used and there're too many text conversions.
Probably the reason for this is that the object read lock is used to
protect fill_textconv() and therefore there is a mutual exclusion
between textconv execution and object reading. Because both are
time-consuming operations, not being able to perform them in parallel
can cause performance drops. To inform the users about this (and other
threading details), let's also add a "NOTES ON THREADS" section to
Documentation/git-grep.txt.
[1]: chromium’s repo at commit 03ae96f (“Add filters testing at DSF=2”,
04-06-2019), after a 'git gc' execution.
Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-16 02:39:58 +00:00
|
|
|
`--open-files-in-pager` is used, forcing a single-threaded execution.
|
|
|
|
|
|
|
|
When grepping the object store (with `--cached` or giving tree objects), running
|
grep docs: describe --no-index further and improve formatting a bit
Improve the description of --no-index, to make it more clear to the users
what this option actually does under the hood, and what's its purpose.
Describe the dependency between --no-index and either of the --cached and
--untracked options, which cannot be used together.
As part of that, shuffle a couple of the options, to make the documentation
flow a bit better, because it makes more sense to describe first the options
that have something in common, and to after that describe an option that does
something differently. In more detail, --cached and --untracked both leave
git-grep(1) in the usual state, in which it treats the directory as a local
git repository, unlike --no-index that makes git-grep(1) treat the directory
not as a git repository.
While there, improve the descriptions of grep worker threads a bit, to give
them better context. Adjust the language a bit, to avoid addressing the
reader directly, which is in general preferred in technical documentation,
because it eliminates the possible element of persuading the user to do
something. In other words, we should be telling the user what our software
can do, instead of telling the user what to do.
Also perform some minor formatting improvements, to make it clear it's the
git commands, command parameters, and configuration option names.
Signed-off-by: Dragan Simic <dsimic@manjaro.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-03-25 20:34:53 +00:00
|
|
|
with multiple threads might perform slower than single-threaded if `--textconv`
|
|
|
|
is given and there are too many text conversions. Thus, if low performance is
|
|
|
|
experienced in this case, it might be desirable to use `--threads=1`.
|
grep: re-enable threads in non-worktree case
They were disabled at 53b8d93 ("grep: disable threading in non-worktree
case", 12-12-2011), due to observable performance drops (to the point
that using a single thread would be faster than multiple threads). But
now that zlib inflation can be performed in parallel we can regain the
speedup, so let's re-enable threads in non-worktree grep.
Grepping 'abcd[02]' ("Regex 1") and '(static|extern) (int|double) \*'
("Regex 2") at chromium's repository[1] I got:
Threads | Regex 1 | Regex 2
---------|------------|-----------
1 | 17.2920s | 20.9624s
2 | 9.6512s | 11.3184s
4 | 6.7723s | 7.6268s
8** | 6.2886s | 6.9843s
These are all means of 30 executions after 2 warmup runs. All tests were
executed on an i7-7700HQ (quad-core w/ hyper-threading), 16GB of RAM and
SSD, running Manjaro Linux. But to make sure the optimization also
performs well on HDD, the tests were repeated on another machine with an
i5-4210U (dual-core w/ hyper-threading), 8GB of RAM and HDD (SATA III,
5400 rpm), also running Manjaro Linux:
Threads | Regex 1 | Regex 2
---------|------------|-----------
1 | 18.4035s | 22.5368s
2 | 12.5063s | 14.6409s
4** | 10.9136s | 12.7106s
** Note that in these cases we relied on hyper-threading, and that's
probably why we don't see a big difference in time.
Unfortunately, multithreaded git-grep might be slow in the non-worktree
case when --textconv is used and there're too many text conversions.
Probably the reason for this is that the object read lock is used to
protect fill_textconv() and therefore there is a mutual exclusion
between textconv execution and object reading. Because both are
time-consuming operations, not being able to perform them in parallel
can cause performance drops. To inform the users about this (and other
threading details), let's also add a "NOTES ON THREADS" section to
Documentation/git-grep.txt.
[1]: chromium’s repo at commit 03ae96f (“Add filters testing at DSF=2”,
04-06-2019), after a 'git gc' execution.
Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-16 02:39:58 +00:00
|
|
|
|
2021-04-09 15:02:50 +00:00
|
|
|
CONFIGURATION
|
|
|
|
-------------
|
|
|
|
|
2022-09-07 08:26:58 +00:00
|
|
|
include::includes/cmd-config-section-all.txt[]
|
2021-04-09 15:02:50 +00:00
|
|
|
|
2022-09-07 08:26:58 +00:00
|
|
|
include::config/grep.txt[]
|
2021-04-09 15:02:50 +00:00
|
|
|
|
2005-09-13 02:39:15 +00:00
|
|
|
GIT
|
|
|
|
---
|
2008-06-06 07:07:32 +00:00
|
|
|
Part of the linkgit:git[1] suite
|