Git Grep颜色选项解释和/或比较 [英] Git Grep color options explained and/or compared

问题描述

我尝试自定义颜色我的Git。

阅读完文档，我找到了我想要设置的选项。

一切都运行正常，除了Grep。
我意识到，我以前没有真正使用它。

我想用相同的调色板设置颜色，但我可以不测试其中的一些...

我不知道 matchContext 和匹配请参阅 matchSelected 和所选

的区别。

matchSelected 为我搜索的实际文本设置颜色，而选择 / code>做？ matchContext 设置了什么？

解决方案

div>

下面是链接的文档说，修剪一点，使其更好地工作：

上下文

    上下文行中的不匹配文本（使用 -A ， -B 或 C ）

matchContext

    匹配上下文行中的文本

matchSelected

;   匹配所选行中的文字

已选择

;   所选行中的不匹配文本

（我省略了匹配 ;我们会把它放回来一会儿）。让我们假设我们运行 git grep findme ，因此我们有一个搜索词。

它们是：

• 匹配文本：这应该是很明显的。我们正在搜索字符串 findme ，因此这是每个字符串的出现。颜色编码匹配对于这些固定字符串和对于模式是不必要的：如果我们正在搜索一个模式，它可能是特别有用的，看看模式匹配什么。




• 上下文行：这里的线索是提及三个标志。你可以获得before上下文（ -B ），after上下文（ -A ）， -C ），这基本上意味着如果你正在搜索 findme ，Git发现，

  
  
  

  请注意，这些前和/或后行可能不在它们中有 findme ，但是它们可能会！




• 所选行：Git这种隐藏意味着什么，但在上面的基础上，它是相当猜测：我们正在搜索单词 findme ，它发生在某些行。所以这些行被选中，它们区别于它们中没有 findme 的任何上下文行;这些线没有选择。

下面是一个例子，在搜索单词 / code>。 Git会以红色着色或，否则不会着色，所以我跑了：

  git -c color.grep.selected = green grep -C 2 -n or 
  

它添加行号以及使用 selected = green 。不幸的是，我无法让StackOverflow为我着色代码，所以我会使用粗体（Git使用绿色）和 italics >



pfod.py-11-

pfod.py-12-这基本上是一个类和OrderedDict的混合体，

pfod.py:13： / i> ，s 或 t。当创建

时，所有字段都设置为 code>

pfod.py-15初始化。

这里我们在两边都有两个未选择的行，根本没有任何颜色。并在一个选定的行中出现两次或。

在某些情况下只是上下文，实际上有一个匹配：

pfod.py-47- self [field ] =无

pfod.py-48-如果len（kwargs）：

pfod.py:49：raise TypeErr 或 （'unexpected kwargs％s'％kwargs.keys（）） / code>

pfod.py-50-如果len（args）：

pfod.py:51：raise TypeErr 或 （'unconsumed args％r'％tuple（args））

pfod.py-52-

pfod.py-53- def __ getattr __ （self，attr）：

这里我们有两个未选择的行边缘，然后两个选定的线与之间的未选择的线。这意味着上下文线也可以选择线！他们可以同时拥有不匹配的文本和匹配的文本。有一些特别奇怪的事情，因为如果上下文线有一个匹配，它成为一个选定的行 - 所以为什么有一个 matchContext ？

通常，设置 color.grep.matchContext 永远不会有任何效果，因为如果是在上下文行中的匹配，它将变为选定的行， color.grep.matchContext 不再适用。但是当使用 -v 时，一切都会被交换。这是文档定义（虽然不是很好）术语所选：

-v ，反转匹配

    选择不匹配的行。

也就是说，grep的 -v em>反转线路选择。通常，找到匹配意味着该行被选中，所以你得到 selected （default = none，但我设置 green 上面）和 matchSelected （默认=粗体红色）颜色。但是使用 -v ，每个具有匹配的行是 de - 选择，只有非匹配行选择。因此，现在选择了 上下文线，并且取消选择匹配线。所以现在匹配行，除了匹配本身，我们得到任何 matchContext 颜色我们设置（默认再次粗体红色）。 （当然，只有在打开上下文时，匹配的行才会出来，因为grep只会将未选择的行作为上下文行输出。也可以设置 color.grep.context

最后：

$ b $

匹配

    匹配文本（与设置 matchContext 和 matchSelected 相同）

这只是设置两者的简写。当 matchContext 是无用的（非 - -v ）时，它有效地作为 matchSelected 。当 matchSelected 无用（ -v ）时，它有效地作为 。 Git在内部使用它来设置粗体红色默认值。

I'm trying to custom color my Git.

After reading through the documentation, I've found my options I wanted to set.

Everything was working fine except the Grep. I've realised, I haven't really used it in the past.

I wanted to set colors for it with the same palette, but I could not test some of them...

I have no idea what matchContext and match refer to and how they're different than matchSelected and selected.

matchSelected sets a color for the actual text I searched for, while as selected referred to the line-level(?) context of that match.

So, what is match doing? What does matchContext set? And where the hell is a good, detailed description for these?

Anyone?

解决方案

Here's what the linked documentation says, trimmed a bit to make it all work out better:

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

(I've left out match; we'll put that back in a moment). Let's say we run git grep findme, just so we have a search word.

The three technical terms, such as they are, here are:

• matching text: This should be pretty obvious. We're searching for the literal string findme so this is each occurrence of that string. Color-coding the match is not as necessary for these kinds of fixed strings as it is for patterns: if we were searching for a pattern, it might be particularly useful to see just what the pattern matched.

• context lines: The clue here is the mention of the three flags. You can get "before" context (-B), "after" context (-A), or both (-C), which basically means that if you are searching for findme and Git finds that, it will print out not just the line with the word findme in it, but also some lines before and after that line.

  Note that these before-and/or-after lines might not have findme in them—but then again, they might!

• selected lines: Git kind of hides what this means, but building on the above, it's fairly guess-able: we were searching for the word findme and it occurred in some line(s). So those lines are selected, which distinguishes them from any context lines that did not have findme in them; those lines are not selected. (But see below!)

Here's an example, in searching for the word or. Git will color or in red, and otherwise do no coloring, by default, so I ran:

git -c color.grep.selected=green grep -C 2 -n or

which adds line numbers as well as using selected=green. Unfortunately I can't get StackOverflow to color code this for me, so instead I'll use bold where Git uses green, and italics where it uses red:

pfod.py-11-
pfod.py-12-This is basically a hybrid of a class and an OrderedDict,
pfod.py:13:or, sort of a data-only class. When an instance of the
pfod.py-14-class is created, all its fields are set to None if not
pfod.py-15-initialized.

Here we had two non-selected lines on either side, not in any color at all; and one selected line in the middle, with two occurrences of or within the one selected line.

In some cases the lines that would just be context, actually have a match:

pfod.py-47- self[field] = None
pfod.py-48- if len(kwargs):
pfod.py:49: raise TypeError('unexpected kwargs %s' % kwargs.keys())
pfod.py-50- if len(args):
pfod.py:51: raise TypeError('unconsumed args %r' % tuple(args))
pfod.py-52-
pfod.py-53- def __getattr__(self, attr):

Here we had two non-selected lines at the outer edges, then two selected lines with a non-selected line in between. This implies context lines can also be selected lines! They can have both non-matching text and matching text. There's something particularly weird about this, because if a context line has a match, it becomes a selected line—so why is there a matchContext at all? If a context line has a match, it changes into a selected line.

Normally, setting color.grep.matchContext never has any effect, because if there is a match within what would have been a context line, it changes into a selected line and color.grep.matchContext no longer applies. But when using -v everything gets swapped around. This is where the documentation defines (albeit not very well) the term selected:

-v, --invert-match

     Select non-matching lines.

That is, grep's -v option inverts the line selection. Normally, finding a match means the line is selected, so you get selected (default = none, but I set green above) and matchSelected (default = "bold red") colors. But with -v, every line that has a match is de-selected, and only non-matching lines are selected. So now what were context lines are selected, and matching lines are de-selected. So now for matching lines we get no color again, except for the match itself, where we get any matchContext color we set (default again "bold red"). (Of course, lines with the match only come out if you turn on context, since grep only outputs non-selected lines as context lines. You can also set color.grep.context to get those -v context-ized lines colorized.)

Finally:

match

     matching text (same as setting matchContext and matchSelected)

This is just shorthand to set both. When matchContext is useless (non--v), it effectively works out as an alias for matchSelected. When matchSelected is useless (-v), it effectively works out as an alias for matchContext. Git uses it internally to set the "bold red" default.

这篇关于Git Grep颜色选项解释和/或比较的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！