Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> Well, if I change `rev.diffopt.use_color != GIT_COLOR_ALWAYS` to
> `rev.diffopt.use_color == GIT_COLOR_AUTO`, then the files will contain
> ugly ANSI color sequences if I run `git format-patch -o . -3`.
>
> The reason is, as I tried to explain, that the use_color field is *not*
> initialized to GIT_COLOR_AUTO (which is equivalent to 2), but to -1.
OK. I thought forcing no-color only when it is set to COLOR_AUTO or
it is set to -1 (the default) would be safer, but I changed my mind.
"when we add a new --color=<something.we.do.not.know.yet>,
overriding that end-user wish with the unconditional no-color is
likely to be seen as bug." was the implicit bias behind that
suggestion, but that is not substanticated and substatiatable.
If we write
if (rev.diffopt.use_color != GIT_COLOR_ALWAYS)
rev.diffopt.use_color = 0;
and if a user of --color=<something.we.do.not.know.yet> wonders why
her output is not colored, it is clear in the code above that we
disable unless it is set with --color=always, so it won't make
fixing such a future breakage harder. In fact, if we did
if (rev.diffopt.use_color == GIT_COLOR_AUTO ||
rev.diffopt.use_color < 0)
rev.diffopt.use_color = 0;
it would make it _harder_ to spot where use_color is turned off when
the person who debugs such an issue.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html