On Tue, Feb 04, 2014 at 02:17:57PM -0800, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > But there's another set of people that I was intending to help with the > > patch, which is people that have set up LESS, and did not necessarily > > care about the "R" flag in the past (e.g., for many years before git > > came along, I set LESS=giM, and never even knew that "R" existed). Since > > git comes out of the box these days with color and the pager turned on, > > that means people with such a setup see broken output from day one. > > > > And I think it is Git's fault here, not the user or the packager. > > I am not particularly itnterested in whose fault it is ;-) If the > user sets LESS himself, he knows how to set it (and if he is setting > it automatically for all of his sessions, he knows where to do so), > and would know better than Git about "less", his pager of choice. > > If he did not know about R and did not see color, that is even > better. Now he knows and his update to his LESS settings will let > him view colors in outputs from programs that are not Git. 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. Anyway, I will leave it at that. It's an unfortunate problem, but one not worth fixing. -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