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

[Felipe Contreras <felipe.contreras@gmail.com>]

On Mon, Feb 23, 2009 at 8:39 AM, Junio C Hamano <gitster@pobox.com> wrote:
> 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.

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