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

[Junio C Hamano <gitster@pobox.com>]

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.

Thanks.