Re: [RFC PATCH] color: respect the $NO_COLOR convention
Junio C Hamano <gits...@pobox.com> writes:
> Leah Neukirchen <l...@vuxu.org> writes:
>
>> NO_COLOR (http://no-color.org/) is a comprehensive approach to disable
>> colors by default for all tools:
>
> The list of software that supports that "convention" is, eh,
> respectable. Is it really a "convention" yet, or yet another thing
> the user needs to worry about?
You are right in calling this out an emerging new thing, but the
second list of that page proves that it will be useful to settle on a
common configuration, and my hope is by getting a few popular projects
on board, others will soon follow. It certainly is easy to implement,
and rather unintrusive. Users which don't know about this feature are
completely unaffected.
>> if (color_stdout_is_tty < 0)
>> color_stdout_is_tty = isatty(1);
>> if (color_stdout_is_tty || (pager_in_use() && pager_use_color)) {
>
> According to no-color.org's FAQ #2, NO_COLOR should affect only the
> "default" behaviour, and should stay back if there is an explicit
> end-user configuration (or command line override). And this helper
> function is called only from want_color() when their is no such
> higher precedence setting, which is in line with the recommendation.
>
> Which is good.
Yes, I took care of that. Should this also be tested? It doesn't
quite fit into the setting of t4026-color.sh I think.
Thanks,
--
Leah Neukirchen <l...@vuxu.org> http://leah.zone
[RFC PATCH] color: respect the $NO_COLOR convention
When the NO_COLOR environment variable is set to any value, default to
disabling color, i.e. resolve 'auto' to false.
NO_COLOR (http://no-color.org/) is a comprehensive approach to disable
colors by default for all tools:
> All command-line software which outputs text with ANSI color added
> should check for the presence of a NO_COLOR environment variable that,
> when present (regardless of its value), prevents the addition of ANSI
> color.
Signed-off-by: Leah Neukirchen <l...@vuxu.org>
---
This is a first stab at implementing NO_COLOR for git, effectively
making it then behave like before colors were enabled by default.
I feel this should be documented somewhere, but I'm not sure where the
best place is. Perhaps in config.ui, or the Git environment variables
(but they all start with GIT_).
color.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/color.c b/color.c
index d48dd947c..59e9c2459 100644
--- a/color.c
+++ b/color.c
@@ -326,6 +326,8 @@ int git_config_colorbool(const char *var, const char *value)
static int check_auto_color(void)
{
+ if (getenv("NO_COLOR"))
+ return 0;
if (color_stdout_is_tty < 0)
color_stdout_is_tty = isatty(1);
if (color_stdout_is_tty || (pager_in_use() && pager_use_color)) {
--
2.16.2
Re: --interactive mode: readline support ⌨⬆
Marcel Partap <mpar...@gmx.net> writes: > Dear git devs, > wouldn't it be great to have the power of readline added to the power > of git interactive commands? Yes, rlwrap will do the job, but still. > Or am I missing something obvious? Am using debian's 2.11.0-2 ... Just use "rlwrap git clean -i". -- Leah Neukirchen <l...@vuxu.org> http://leah.zone
