Re: [PATCH] builtin/config.c: don't print a newline with --color

> Jeff King <peff@peff.net> writes:
>
>> I'm not sure I agree. Colors have always been special, and
>> "--type=color" was advertised as a replacement for "--get-color". And
>> "--get-color" never output the newline.
>
> OK, that part of the motivation I completely missed.  If end-users
> and scripters are happy with the behaviour of --get-color that does
> not terminate its output with LF (which I think is a reasonable
> thing to do, as "color" is special in that context, i.e. having a
> dedicated --get option suitable for that type), as we advertise
> "--type=color" is the same as "--get-color" (only better), we need
> to special case it, and omitting LF at the end similarly does make
> sense.
>
>> With respect to backwards compatibility, my thinking on the matter was
>> basically:
>>
>>   1. Since --type=color was supposed to be a drop-in replacement for
>>      --get-color, it's a bug that they don't behave the same.
>>
>>   2. It's a fairly recent feature, so nobody really noticed the bug
>>      until recently (and it was in fact me who noticed and got annoyed
>>      by it). If it were an ancient behavior, we might think about
>>      retaining even bug compatibility, but that's not the case here.
>
> Now I think "we weren't consistent to begin with with --get-color,
> and treating --type=color as a special case is justifiable"; and I
> agree with the above two points.