Git Grep 颜色选项解释 and/or 比较
Git Grep color options explained and/or compared
我正在尝试自定义颜色 Git。
通读 documentation 后,我找到了我想要设置的选项。
除 Grep 外,一切正常。
我发现了,我以前没有真正用过它。
我想用相同的调色板为它设置颜色,但我无法测试其中的一些...
我不知道 matchContext
和 match
指的是什么以及它们与 matchSelected
和 selected
有何不同。
matchSelected
为我搜索的实际文本设置颜色,而 selected
指的是行级 (?) context匹配。
那么,match
在做什么? matchContext
设置了什么?到底哪里有关于这些的详细详细描述?
有人吗?
以下是链接文档的内容,经过一些删减以使其更好地发挥作用:
context
non-matching text in context lines (when using -A
, -B
, or -C
)
matchContext
matching text in context lines
matchSelected
matching text in selected lines
selected
non-matching text in selected lines
(我遗漏了 match
;我们稍后会把它放回去)。假设我们 运行 git grep findme
,这样我们就有了一个搜索词。
这里是三个技术术语:
匹配文本:这应该很明显。我们正在搜索文字字符串 findme
所以这是该字符串的每次出现。对于这些类型的固定字符串,对匹配项进行颜色编码并不像对于模式那样必要:如果我们正在搜索一种模式,那么查看模式匹配的内容可能特别有用。
context lines:这里的线索是提到了三个标志。您可以获得“之前”上下文 (-B
)、“之后”上下文 (-A
) 或两者 (-C
),这基本上意味着如果您正在搜索 findme
和 Git 发现,它不仅会打印出其中包含单词 findme
的行,还会打印出该行前后的一些行。
请注意,这些 before-and/or-after 行可能 而不是 其中包含 findme
— 但话又说回来,它们可能!
selected lines: Git 有点隐藏了这意味着什么,但是在上面的基础上,它是相当可以猜测的:我们正在搜索对于单词 findme
并且它出现在某些行中。所以这些行是 selected,这将它们与任何没有 findme
的上下文行区分开来;这些行未被选中。 (但见下文!)
这是一个示例,搜索单词 or
。 Git 会将 or
着色为红色,否则默认不着色,所以我 运行:
git -c color.grep.selected=green grep -C 2 -n or
添加行号以及使用 selected=green
。不幸的是,我无法让 Whosebug 为我进行颜色编码,所以我将使用 bold,其中 Git 使用绿色,italics 使用红色的地方:
pfod.py-11-
pfod.py-12-This is basically a hybrid of a class and an OrderedDict,
<b>pfod.py:13:</b><i>或</i><b>,s</b><i>or</i><b>t 的纯数据 class。当</b>
的一个实例
pfod.py-14-class is created, all its fields are set to None if not
pfod.py-15-initialized.
这里我们在两边各有两条未选中的线,根本没有任何颜色;和中间的一个选定行,在一个选定行中出现两次 or
。
在某些情况下, 只是上下文的行实际上有匹配项:
pfod.py-47- self[field] = None
pfod.py-48- if len(kwargs):
<b>pfod.py:49: 提高类型错误</b><i>或</i><b>('unexpected kwargs %s' % kwargs.keys())</b>
pfod.py-50- if len(args):
<b>pfod.py:51: 引发 TypeErr</b><i> 或 </i><b>('unconsumed args %r' % tuple(参数))</b>
pfod.py-52-
pfod.py-53- def <code>__getattr__
(self, attr):
这里我们在外边缘有两条未选中的线,然后是两条选中的线,中间有一条未选中的线。这意味着上下文行也可以是选定行!它们可以同时具有 不匹配的 文本和 匹配的 文本。这有一些特别奇怪的地方,因为如果上下文行有匹配项,它就会成为选定行——那么为什么会有 matchContext
呢?如果上下文行有匹配项,它将变为选定行。
通常情况下,设置 color.grep.matchContext
永远不会有任何效果,因为如果 是 上下文行中的匹配项,它会变为选定行并且color.grep.matchContext
不再适用。但是当使用 -v
时,一切都会被交换。这是 the documentation 定义(尽管不是很好)术语 selected:
-v
, --invert-match
Select non-matching lines.
也就是说,grep 的 -v
选项 反转 行选择。通常,找到匹配意味着该行被选中,所以你得到selected
(默认=none,但我上面设置了green
)和matchSelected
(默认=“粗体红色“) 颜色。但是对于 -v
,匹配的每一行都是 de-选择的,只有 非-匹配的行被选择。所以现在 是 上下文行被选中,匹配行被取消选择。所以现在对于匹配线,我们再次没有颜色,除了匹配本身,在那里我们获得我们设置的任何 matchContext
颜色(再次默认为“粗体红色”)。 (当然,匹配的行只有在你打开上下文时才会出现,因为 grep 只输出未选择的行作为上下文行。你也可以设置 color.grep.context
来获取那些 -v
上下文化的行着色。)
最后:
match
matching text (same as setting matchContext
and matchSelected
)
这只是 shorthand 设置两者。当 matchContext
无用时(非 -v
),它实际上是 matchSelected
的别名。当 matchSelected
无用时 (-v
),它实际上是 matchContext
的别名。 Git 在内部使用它来设置“粗体红色”默认值。
I wanted to set colors for it with the same palette, but I could not test some of them.
检查您是否仍然需要 compare/test 具有 Git 2.35(2022 年第一季度,5 年后)的那些颜色:
“git grep
"(man) 使用的调色板已更新为与 GNU grep 相匹配。
参见 commit b83f99c (05 Jan 2022) by Lénaïc Huard (L3n41c
)。
(由 Junio C Hamano -- gitster
-- in commit c0450ca 合并,2022 年 1 月 10 日)
grep
: align default colors with GNU grep ones
Signed-off-by: Lénaïc Huard
git-grep
(man) shares a lot of options with the standard grep tool.
Like GNU grep, it has coloring options to highlight the matching text.
And like it, it has options to customize the various colored parts.
This patch updates the default git-grep
colors to make them match the GNU grep default ones.
It was possible to get the same result by setting the various color.grep.<slot>
options, but this patch makes git grep --color
(man) share the same color scheme as grep --color
by default without any user configuration.
我正在尝试自定义颜色 Git。
通读 documentation 后,我找到了我想要设置的选项。
除 Grep 外,一切正常。 我发现了,我以前没有真正用过它。
我想用相同的调色板为它设置颜色,但我无法测试其中的一些...
我不知道 matchContext
和 match
指的是什么以及它们与 matchSelected
和 selected
有何不同。
matchSelected
为我搜索的实际文本设置颜色,而 selected
指的是行级 (?) context匹配。
那么,match
在做什么? matchContext
设置了什么?到底哪里有关于这些的详细详细描述?
有人吗?
以下是链接文档的内容,经过一些删减以使其更好地发挥作用:
context
non-matching text in context lines (when using
-A
,-B
, or-C
)
matchContext
matching text in context lines
matchSelected
matching text in selected lines
selected
non-matching text in selected lines
(我遗漏了 match
;我们稍后会把它放回去)。假设我们 运行 git grep findme
,这样我们就有了一个搜索词。
这里是三个技术术语:
匹配文本:这应该很明显。我们正在搜索文字字符串
findme
所以这是该字符串的每次出现。对于这些类型的固定字符串,对匹配项进行颜色编码并不像对于模式那样必要:如果我们正在搜索一种模式,那么查看模式匹配的内容可能特别有用。context lines:这里的线索是提到了三个标志。您可以获得“之前”上下文 (
-B
)、“之后”上下文 (-A
) 或两者 (-C
),这基本上意味着如果您正在搜索findme
和 Git 发现,它不仅会打印出其中包含单词findme
的行,还会打印出该行前后的一些行。请注意,这些 before-and/or-after 行可能 而不是 其中包含
findme
— 但话又说回来,它们可能!selected lines: Git 有点隐藏了这意味着什么,但是在上面的基础上,它是相当可以猜测的:我们正在搜索对于单词
findme
并且它出现在某些行中。所以这些行是 selected,这将它们与任何没有findme
的上下文行区分开来;这些行未被选中。 (但见下文!)
这是一个示例,搜索单词 or
。 Git 会将 or
着色为红色,否则默认不着色,所以我 运行:
git -c color.grep.selected=green grep -C 2 -n or
添加行号以及使用 selected=green
。不幸的是,我无法让 Whosebug 为我进行颜色编码,所以我将使用 bold,其中 Git 使用绿色,italics 使用红色的地方:
pfod.py-11-
pfod.py-12-This is basically a hybrid of a class and an OrderedDict,
<b>pfod.py:13:</b><i>或</i><b>,s</b><i>or</i><b>t 的纯数据 class。当</b>
的一个实例
pfod.py-14-class is created, all its fields are set to None if not
pfod.py-15-initialized.
这里我们在两边各有两条未选中的线,根本没有任何颜色;和中间的一个选定行,在一个选定行中出现两次 or
。
在某些情况下, 只是上下文的行实际上有匹配项:
pfod.py-47- self[field] = None
pfod.py-48- if len(kwargs):
<b>pfod.py:49: 提高类型错误</b><i>或</i><b>('unexpected kwargs %s' % kwargs.keys())</b>
pfod.py-50- if len(args):
<b>pfod.py:51: 引发 TypeErr</b><i> 或 </i><b>('unconsumed args %r' % tuple(参数))</b>
pfod.py-52-
pfod.py-53- def <code>__getattr__
(self, attr):
这里我们在外边缘有两条未选中的线,然后是两条选中的线,中间有一条未选中的线。这意味着上下文行也可以是选定行!它们可以同时具有 不匹配的 文本和 匹配的 文本。这有一些特别奇怪的地方,因为如果上下文行有匹配项,它就会成为选定行——那么为什么会有 matchContext
呢?如果上下文行有匹配项,它将变为选定行。
通常情况下,设置 color.grep.matchContext
永远不会有任何效果,因为如果 是 上下文行中的匹配项,它会变为选定行并且color.grep.matchContext
不再适用。但是当使用 -v
时,一切都会被交换。这是 the documentation 定义(尽管不是很好)术语 selected:
-v
,--invert-match
Select non-matching lines.
也就是说,grep 的 -v
选项 反转 行选择。通常,找到匹配意味着该行被选中,所以你得到selected
(默认=none,但我上面设置了green
)和matchSelected
(默认=“粗体红色“) 颜色。但是对于 -v
,匹配的每一行都是 de-选择的,只有 非-匹配的行被选择。所以现在 是 上下文行被选中,匹配行被取消选择。所以现在对于匹配线,我们再次没有颜色,除了匹配本身,在那里我们获得我们设置的任何 matchContext
颜色(再次默认为“粗体红色”)。 (当然,匹配的行只有在你打开上下文时才会出现,因为 grep 只输出未选择的行作为上下文行。你也可以设置 color.grep.context
来获取那些 -v
上下文化的行着色。)
最后:
match
matching text (same as setting
matchContext
andmatchSelected
)
这只是 shorthand 设置两者。当 matchContext
无用时(非 -v
),它实际上是 matchSelected
的别名。当 matchSelected
无用时 (-v
),它实际上是 matchContext
的别名。 Git 在内部使用它来设置“粗体红色”默认值。
I wanted to set colors for it with the same palette, but I could not test some of them.
检查您是否仍然需要 compare/test 具有 Git 2.35(2022 年第一季度,5 年后)的那些颜色:
“git grep
"(man) 使用的调色板已更新为与 GNU grep 相匹配。
参见 commit b83f99c (05 Jan 2022) by Lénaïc Huard (L3n41c
)。
(由 Junio C Hamano -- gitster
-- in commit c0450ca 合并,2022 年 1 月 10 日)
grep
: align default colors with GNU grep onesSigned-off-by: Lénaïc Huard
git-grep
(man) shares a lot of options with the standard grep tool.
Like GNU grep, it has coloring options to highlight the matching text.
And like it, it has options to customize the various colored parts.This patch updates the default
git-grep
colors to make them match the GNU grep default ones.It was possible to get the same result by setting the various
color.grep.<slot>
options, but this patch makesgit grep --color
(man) share the same color scheme asgrep --color
by default without any user configuration.