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

[Junio C Hamano <gitster@pobox.com>]

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.