Junio C Hamano <gitster@xxxxxxxxx> writes: > 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 > 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. Just to avoid an awkward situation where the ball gets dropped and left on the floor forgotten, the above does not mean I am 100% happy with the patch as posted. There is no mention of --get-color anywhere, let alone it shows the ANSI sequence without traililng LF, which I would consider to be the most important part of the justification. It is much stronger than "I expected there won't be any trailing LF from 'git config'", which was the only thing I managed to read in the original and led to my response.
