Re: [RFC/PATCH] revision.c: add --format option for 'git log'

> Felipe Contreras <felipe.contreras@gmail.com> 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.