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

On Mon, Feb 23, 2009 at 8:39 AM, Junio C Hamano [off-list ref] wrote:

Felipe Contreras [off-list ref] writes:

quoted

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.

The color of a bikeshed is essentially irrelevant, red vs blue makes
almost no difference. Are you suggesting that --pretty and --format
are essentially the same and therefore arguing about one vs the other
is a waste of time?

Words have associated meaning, choosing one over the other makes a big
difference, sometimes huge. Image what would have happened if
programming languages would have chosen 'check' instead of 'if'...

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'm saying we should be in point B (--format), you are saying we are
already in point A (--pretty), it would have been nicer to choose B
since day one, but we didn't.

I'm still saying we should be in point B, even if the path from A to B
is unclear, and maybe tedious, it's still an improvement, and as such
it must be done eventually.

AFAIK git's user interface is one of the big areas for improvement,
and a common complaint from anti-gitters... this is an example of one
of the issues.

Perhaps there should be a way to handle this "it would have been very
nice if it were like that from day one" cases, maybe queue the patches
on a separate branch until some big release? 1.7.x? Or maybe in the
meantime generate a warning: X is deprecated, please use Y instead.

The issue that comes into my mind is the old 'git-foo' format. The
switch wasn't handled correctly according to many people... most users
noticed until it was very late. That's why deprecation warnings make
sense.

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,

I would rather say --pretty is history, if you have 1.7.x, use --format.

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.

Yeah, I would like --oneline too.

-- 
Felipe Contreras