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. -Peff -- 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