Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: > It's not breakage that needs to be fixed, it's UI improvement,... > ... Don't you > think that --format=email is more natural than --pretty=email? That heavily depends on when you ask. If it _were_ during the period when we were actively building this bikeshed, then I would have said "yeah, that color looks prettier". But a proposal to repaint the bikeshed in a different color long after it was built needs to be supported by an argument that is much stronger than "I do not like the current one, I am improving it by painting in a better color." IOW, you came too late to just bikeshed. People already are used to finding the shed in the scenery by looking for that original color, however ugly the color might be. The answer to your question has to become quite different when you take that into account; otherwise you are being irresponsible to your users. This falls into the "it would have been very nice if it were like that from day one. I'd happily agree with you,... only if we didn't do it the way we originally did" category. You cannot call such a change an improvement without thinking why the above statement is heavily qualified with "if it were" and "only if we didn't". I am actually Ok with having a synonym --format that works *identically* with how --pretty works, and then update how both of them work to make them better perhaps in a follow-up patch. You accept style names that you recognize as before, and instead of erroring out, if the unrecognized string has % in it, pretend as if "tformat:" was in front of it. It still has the "two keywords for the same thing" misfortune, but that is something you cannot avoid. You yourself would need to say "newer git would accept --format=short, but with the version shipped by your distribution you may have to say --pretty instead" when teaching new people who come after you. Hopefully not many people would complain as long as you do not break the existing --pretty, Also I like Linus's --oneline === --pretty=oneline, but I haven't audited the list of double-dash options our commands take that are unrelated to pretty-printing styles. If there are ones that look or sound similar to the recognized style names (or if some commands may want to use the word for controlling their own operation that is not related to pretty-printing in their future enhancement), it would cause grief to us down the road. The only one I can think of offhand is --full, so this probably is Ok. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
