On Tue, Feb 04, 2014 at 02:45:11PM -0800, Yuri wrote:

> On 02/04/2014 14:25, Jeff King wrote:
> >Right. If git just disabled the color, I think that would be sane (and
> >that is what my patch was shooting for). But somebody who sees:
> >
> >   $ git log
> >   ESC[33mcommit 3c6b385c655a52fd9db176ce1e01469dc9954f91ESC[mESC[33m
> >   (ESC[1;36mHEADESC[mESC[33m, ESC[1;32mjk/meta-makeESC[mESC[33m)ESC[m
> >
> >does not necessarily know what is going on. They do not know that it is
> >a "less" problem, nor that their less settings are relevant. They only
> >see that Git is broken out of the box.
> Maybe, instead of doing all the elaborate guess and assumption work,
> have configure script check if the current PAGER supports colors and
> build git accordingly?
> configure could run the pager as one of its tests, and determine if
> "ESC" appears on the output.

But this is not a build-time problem, but rather a run-time problem. We
do not know what the environment of the user will be at run-time.

The safest thing would be to turn off auto-color when LESS (or any of
the pager environment variables) is set at all (and not worry about
whether "R" is set; only know that _we_ are not setting it, so we cannot
count on it). But that would potentially inconvenience a lot of people
whose default color would suddenly go away.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to