[PATCH 0/1] grep: align default colors with GNU grep ones

[PATCH 0/1] grep: align default colors with GNU grep ones

[Lénaïc Huard]

git-grep 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 [1].

It was possible to get the same result by setting the various `color.grep.<slot>`
options, but this patch makes `git grep --color` share the same color scheme as
`grep --color` by default without any user configuration.

[1] https://www.man7.org/linux/man-pages/man1/grep.1.html#ENVIRONMENT

Lénaïc Huard (1):
  grep: align default colors with GNU grep ones

 grep.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

-- 
2.34.1

[PATCH 1/1] grep: align default colors with GNU grep ones

[Lénaïc Huard]

Signed-off-by: Lénaïc Huard <lenaic@lhuard.fr>
---
 grep.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/grep.c b/grep.c
index fe847a0111..ca4f321cb3 100644
--- a/grep.c
+++ b/grep.c
@@ -26,10 +26,10 @@ static struct grep_opt grep_defaults = {
 	.pattern_type_option = GREP_PATTERN_TYPE_UNSPECIFIED,
 	.colors = {
 		[GREP_COLOR_CONTEXT] = "",
-		[GREP_COLOR_FILENAME] = "",
+		[GREP_COLOR_FILENAME] = GIT_COLOR_MAGENTA,
 		[GREP_COLOR_FUNCTION] = "",
-		[GREP_COLOR_LINENO] = "",
-		[GREP_COLOR_COLUMNNO] = "",
+		[GREP_COLOR_LINENO] = GIT_COLOR_GREEN,
+		[GREP_COLOR_COLUMNNO] = GIT_COLOR_GREEN,
 		[GREP_COLOR_MATCH_CONTEXT] = GIT_COLOR_BOLD_RED,
 		[GREP_COLOR_MATCH_SELECTED] = GIT_COLOR_BOLD_RED,
 		[GREP_COLOR_SELECTED] = "",
-- 
2.34.1

Re: [PATCH 0/1] grep: align default colors with GNU grep ones

[Junio C Hamano]

Lénaïc Huard <lenaic@lhuard.fr> writes:

> git-grep 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 [1].
>
> It was possible to get the same result by setting the various `color.grep.<slot>`
> options, but this patch makes `git grep --color` share the same color scheme as
> `grep --color` by default without any user configuration.

I am not a huge fan of adjusting our defaults to other people's
default, since it will lead do an inevitable "Why don't they adjust
to match ours?" question, plus "We've been happily using the default
coloring, and you suddenly changed it to something ugly. We want our
color back and we do not care that now you match what GNU does".

The UI color choice is so personal, which does not help us either.

Having said that, I'll keep an eye on what others say on this
thread.

Thanks.

Re: [PATCH 0/1] grep: align default colors with GNU grep ones

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Lénaïc Huard <lenaic@lhuard.fr> writes:
>
>> git-grep 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 [1].
>>
>> It was possible to get the same result by setting the various `color.grep.<slot>`
>> options, but this patch makes `git grep --color` share the same color scheme as
>> `grep --color` by default without any user configuration.
>
> I am not a huge fan of adjusting our defaults to other people's
> default, since it will lead do an inevitable "Why don't they adjust
> to match ours?" question, plus "We've been happily using the default
> coloring, and you suddenly changed it to something ugly. We want our
> color back and we do not care that now you match what GNU does".
>
> The UI color choice is so personal, which does not help us either.
>
> Having said that, I'll keep an eye on what others say on this
> thread.

It's been a bit more than a week and it seems nobody else is
interested in supporting this change [*1*].

Whether we want this change or not, I just noticed that the real
patch [1/1] has no commit log message, and most of what is in the
above "cover letter" would would make a good material for the log
message.  Perhaps we'd want to redo the log message if it turns out
that we want to take this change.

Thanks.


[Footnote]

*1* "Nobody is against" is not even an argument, by the way.  If we
    took changes only because they see no objection, we will force
    reviewers to shoot down all nonsense changes and wear them down.
    The default for any new change is "not to apply" until it turns
    out that it is beneficial.

[PATCH v2 0/1] grep: align default colors with GNU grep ones

[Lénaïc Huard]

I’ve re-rolled this patch only to move the change description from the
cover letter to the commit message.
Except from that, there is no change in the code at all.

Lénaïc Huard (1):
  grep: align default colors with GNU grep ones

 grep.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

-- 
2.34.1

[PATCH v2 1/1] grep: align default colors with GNU grep ones

[Lénaïc Huard]

git-grep 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 [1].

It was possible to get the same result by setting the various `color.grep.<slot>`
options, but this patch makes `git grep --color` share the same color scheme as
`grep --color` by default without any user configuration.

[1] https://www.man7.org/linux/man-pages/man1/grep.1.html#ENVIRONMENT

Signed-off-by: Lénaïc Huard <lenaic@lhuard.fr>
---
 grep.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/grep.c b/grep.c
index fe847a0111..ca4f321cb3 100644
--- a/grep.c
+++ b/grep.c
@@ -26,10 +26,10 @@ static struct grep_opt grep_defaults = {
 	.pattern_type_option = GREP_PATTERN_TYPE_UNSPECIFIED,
 	.colors = {
 		[GREP_COLOR_CONTEXT] = "",
-		[GREP_COLOR_FILENAME] = "",
+		[GREP_COLOR_FILENAME] = GIT_COLOR_MAGENTA,
 		[GREP_COLOR_FUNCTION] = "",
-		[GREP_COLOR_LINENO] = "",
-		[GREP_COLOR_COLUMNNO] = "",
+		[GREP_COLOR_LINENO] = GIT_COLOR_GREEN,
+		[GREP_COLOR_COLUMNNO] = GIT_COLOR_GREEN,
 		[GREP_COLOR_MATCH_CONTEXT] = GIT_COLOR_BOLD_RED,
 		[GREP_COLOR_MATCH_SELECTED] = GIT_COLOR_BOLD_RED,
 		[GREP_COLOR_SELECTED] = "",
-- 
2.34.1

Re: [PATCH 0/1] grep: align default colors with GNU grep ones

[Lénaïc Huard]

Le lundi 3 janvier 2022, 23:40:46 CET Junio C Hamano a écrit :
> Junio C Hamano <gitster@pobox.com> writes:
> > […]
> > 
> > The UI color choice is so personal, which does not help us either.
> > 
> > Having said that, I'll keep an eye on what others say on this
> > thread.
> 
> It's been a bit more than a week and it seems nobody else is
> interested in supporting this change [*1*].
> 
> Whether we want this change or not, I just noticed that the real
> patch [1/1] has no commit log message, and most of what is in the
> above "cover letter" would would make a good material for the log
> message.  Perhaps we'd want to redo the log message if it turns out
> that we want to take this change.
> 
> […]

Thank you very much for your feedback.

I’ve just re-rolled the patch to only move the cover letter to the commit 
message in case the patch is eventually accepted.

I proposed this patch because I thought that people picky about colors would 
have customized them anyway and people less picky about colors would leave the 
default and would find smarter to have the same color scheme for different tools 
doing the same thing (`git grep` and `GNU grep`).
I choose to align `git grep` on `GNU grep` because the latter has a more 
colorful scheme and elements already colored in both schemes are already 
sharing the same color.

I however understand your points and I would understand if the patch is 
dropped if it isn’t worth having to justify a change of default values.