"brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes: > In general, this is made worse because Git doesn't honor the unofficial > but widely supported NO_COLOR[0], so reading the documentation is > obligatory. I vaguely recall that we were contacted by NO_COLOR folks to be an early supporter of their cause to break the chicken-and-egg problem they were hagving, and (unhelpfully) answered with "sure, when we see enough people support it---otherwise we'd end up having to keep essentially a dead code that supports a convention that is not all that useful". > [0] https://no-color.org/ I wonderr if it is just a matter of hooking into want_color(), like this? color.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git c/color.c w/color.c index 64f52a4f93..2516ef7275 100644 --- c/color.c +++ w/color.c @@ -373,12 +373,17 @@ int want_color_fd(int fd, int var) * we always write the same value, but it's still wrong. This function * is listed in .tsan-suppressions for the time being. */ - + static int no_color = -1; static int want_auto[3] = { -1, -1, -1 }; if (fd < 1 || fd >= ARRAY_SIZE(want_auto)) BUG("file descriptor out of range: %d", fd); + if (no_color < 0) + no_color = !!getenv("NO_COLOR"); + if (no_color) + return 0; + if (var < 0) var = git_use_color_default;
