Re: [PATCH] make color.ui default to 'auto'

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes:

> Junio C Hamano <gitster@xxxxxxxxx> writes:
>
>> I think you are missing the entire point, which is not "is anyone
>> harmed?"
>
> Again, it is. If the new default is really harmful for too many people,
> then documentations will have to mention how to fix it.
>
> And really, I do not forsee any newbie-oriented starting with "here's
> how to disable colors in case you need it", because of the reasons
> mentionned in the message.
>
>> Our recommendation has been "use color=auto"
>
> Not really. Neither Documentation/gittutorial.txt nor
> Documentation/user-manual.txt mention colors. Pro Git mentions it, but
> more as a possibility than as a recommandation. This is the
> recommandation of the rest of the world, not "ours".

Do you mean the git users who learn and use Git without being in the
circle of people who updates Documentation/ hierarchy "the rest of
the world"?

I think that is a flawed mentality.  They are part of "us".

> It's not "either we update the docs or we update the code", it's "follow
> what the rest of the world is doing", and "rest of the world" has to
> imply a notion of majority (not all tutorials talk about color.ui).

Yes, exactly.

Read the statement you made again, with the assumption that
everybody ("the rest of the world") already knows (and/or agreed to)
colouring is a good thing.

> ... Other beginners do not know about
> color.ui=auto, and may not discover it by themselves, hence live with
> black&white outputs while they may have prefered colors.
>
> A few people (e.g. color-blind) prefer having no colors, but they can
> easily set color.ui=never for this (and googling "disable colors in git"
> already tells them how to do so).

Now, realize that after switching the default, these "few people"
have to live with distracting (or unreadable) output.  Because these
people are minority, their websearch "disable colors in git" will by
definition have smaller number of hits than "enable colors in git"
the above claims people "may not discover it by themselves".  In a
way, you are making things even harder because these minority do not
have many similar others to ask help for.

That is the honest way to express what you said in the second
paragraph.

If we really want to justify the changing of the default, we should
not try to weasel out by using asymmetric wording from the fact that
we are making things less convenient for one kind of people.  We
should be honest and say what we are doing: "it will make things
easier for majority while making it less convenient for minority".

I am however saying that in this case, we are better off not even
trying to come up with such a lame excuse for us to hurt color-blind
people in order to make things easier for majority.  Just saying
"the rest of the world prefer automatic color and that is what we
recommend, so make the code match" should be sufficient.

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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]