Re: [PATCH] builtin/config.c: don't print a newline with --color
- Date: Mon, 04 Mar 2019 13:28:01 +0900
- From: Junio C Hamano <gitster@xxxxxxxxx>
- Subject: Re: [PATCH] builtin/config.c: don't print a newline with --color
Jeff King <peff@xxxxxxxx> 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
> With respect to backwards compatibility, my thinking on the matter was
> 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.