On Tue, Feb 04, 2014 at 02:17:57PM -0800, Junio C Hamano wrote:

> Jeff King <p...@peff.net> 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.

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