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

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 4, 2019, 04:28 UTC
Message-ID: <xmqqlg1vw9f2.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20190303174214.GF23811@sigill.intra.peff.net>

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.

Show 10 quoted lines

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