Jeff King <p...@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.
