Re: Updated to v2.14.2 on macOS; git add --patch broken

[Tsvi Mostovicz <ttmost@gmail.com>]

I also don't remember why I set it, and as such I removed it.

A helpful hint as to a bad config option would've been great.
Something along the lines of "The use of color.ui = always is not
recommended", with a flag allowing you to disable said warning.

Thanks,

Tsvi
Tsvi Mostovicz
ttmost@gmail.com
www.linkedin.com/in/tsvim


On Tue, Oct 3, 2017 at 12:10 PM, Jeff King <peff@peff.net> wrote:
> On Tue, Oct 03, 2017 at 05:56:53PM +0900, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>>
>> > Note that I'm arguing that it's a foot-gun even without scripts in the
>> > picture at all. Forget about plumbing versus porcelain. If you set
>> > color.ui to "always", you're going to get unexpected and confusing
>> > results from time to time.
>>
>> Really?
>>
>> I would think you would consistently get ANSI colored output in any
>> medium, even in files that you would later "cat" or "less -R" to
>> view.  Is that unexpected?  Those who set "always" (I am not among
>> them, of course) would expect that, I would think.
>
> Those cases might be expected. But color when piping to grep or sed are
> not. I guess you can lump those under "well, they should be using
> plumbing, of course" but I don't think that's very realistic. People do
> ad-hoc pipes in their shells all the time (well, I assume so; I
> certainly do).
>
> I don't argue that people don't have a need to write colors to a
> non-terminal. Certainly they do. I argue that setting it in your on-disk
> config is likely to have it trigger at other times when it's unexpected
> and inconvenient.
>
> I dunno. Maybe I am wrong, because certainly I never set it. We've had
> two reports on the list since v2.14.2. The motivation for the first was
> "I have no idea why I set that, and I'll switch to auto". This is the
> second.
>
> -Peff