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

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

[Felipe Contreras]

--format=:foo is a shorthand for --pretty=tformat:foo, otherwise this
new option acts just like --pretty=foo, except it's more intuitive for
users of 'git log'.

As discussed in the mailing list, this is implemented as an undocumented
option. The specifics of the implementation were suggested by Junio C
Hamano.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 revision.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/revision.c b/revision.c
index 286e416..6796e39 100644
--- a/revision.c
+++ b/revision.c
@@ -1147,6 +1147,16 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
 	} else if (!prefixcmp(arg, "--pretty=")) {
 		revs->verbose_header = 1;
 		get_commit_format(arg+9, revs);
+	} else if (!prefixcmp(arg, "--format=")) {
+		char *modified = NULL;
+		revs->verbose_header = 1;
+		if (arg[9] == ':') {
+			modified = xmalloc(strlen(arg+9) + 7 + 1);
+			strcpy(modified, "tformat");
+			strcat(modified, arg+9);
+		}
+		get_commit_format(modified ? modified : arg+9, revs);
+		free(modified);
 	} else if (!strcmp(arg, "--graph")) {
 		revs->topo_order = 1;
 		revs->rewrite_parents = 1;
-- 
1.6.1.3

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

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> --format=:foo is a shorthand for --pretty=tformat:foo, otherwise this
> new option acts just like --pretty=foo, except it's more intuitive for
> users of 'git log'.

It's been quite a long time since the earlier discussion, but I wonder why
you need the colon before "foo" for this new shorthand.  I *think* you are
also introducing "--format=short" as a synonym to "--pretty=short", but
I do not think it is necessary.

> As discussed in the mailing list, this is implemented as an undocumented
> option.

Maybe somebody wants to document it.

Needs trivial tests.

> +	} else if (!prefixcmp(arg, "--format=")) {
> +		char *modified = NULL;
> +		revs->verbose_header = 1;
> +		if (arg[9] == ':') {
> +			modified = xmalloc(strlen(arg+9) + 7 + 1);
> +			strcpy(modified, "tformat");
> +			strcat(modified, arg+9);
> +		}
> +		get_commit_format(modified ? modified : arg+9, revs);
> +		free(modified);

	struct strbuf fmt = STRBUF_INIT;
        revs->verbose_header = 1;
        strbuf_addf(&fmt, "tformat:%s", arg + 9);
        get_commit_format(fmt.buf, revs);
        strbuf_release(&fmt);

>  	} else if (!strcmp(arg, "--graph")) {
>  		revs->topo_order = 1;
>  		revs->rewrite_parents = 1;
> -- 
> 1.6.1.3

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

[Felipe Contreras]

On Sun, Feb 22, 2009 at 6:49 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> --format=:foo is a shorthand for --pretty=tformat:foo, otherwise this
>> new option acts just like --pretty=foo, except it's more intuitive for
>> users of 'git log'.
>
> It's been quite a long time since the earlier discussion, but I wonder why
> you need the colon before "foo" for this new shorthand.  I *think* you are
> also introducing "--format=short" as a synonym to "--pretty=short", but
> I do not think it is necessary.

Well, my hope was to replace --pretty=short with --format=short, but
you said that would break other scripts.

>> As discussed in the mailing list, this is implemented as an undocumented
>> option.
>
> Maybe somebody wants to document it.

Ah, I would gladly add the documentation, shall I write that it's an
'alternative' option similar to --pretty?

> Needs trivial tests.

All right.

>> +     } else if (!prefixcmp(arg, "--format=")) {
>> +             char *modified = NULL;
>> +             revs->verbose_header = 1;
>> +             if (arg[9] == ':') {
>> +                     modified = xmalloc(strlen(arg+9) + 7 + 1);
>> +                     strcpy(modified, "tformat");
>> +                     strcat(modified, arg+9);
>> +             }
>> +             get_commit_format(modified ? modified : arg+9, revs);
>> +             free(modified);
>
>        struct strbuf fmt = STRBUF_INIT;
>        revs->verbose_header = 1;
>        strbuf_addf(&fmt, "tformat:%s", arg + 9);
>        get_commit_format(fmt.buf, revs);
>        strbuf_release(&fmt);

Ah, I felt there must be a utility like that but I couldn't find
examples of that. Thanks.

-- 
Felipe Contreras

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

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> On Sun, Feb 22, 2009 at 6:49 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>>> --format=:foo is a shorthand for --pretty=tformat:foo, otherwise this
>>> new option acts just like --pretty=foo, except it's more intuitive for
>>> users of 'git log'.
>>
>> It's been quite a long time since the earlier discussion, but I wonder why
>> you need the colon before "foo" for this new shorthand.  I *think* you are
>> also introducing "--format=short" as a synonym to "--pretty=short", but
>> I do not think it is necessary.
>
> Well, my hope was to replace --pretty=short with --format=short, but
> you said that would break other scripts.

It is not just scripts you break.  You also break people's trained
fingers.

You can specify the kind of canned pretty printing with --pretty=short,
and it is not any longer to type than --format.  For use in scripts that
you write once and forget, there is no need to even apply this patch.

The only reason why new --format=<fmt> could be an useful addition is
because --pretty=format:<fmt> may be too long to type interactively.

>>> As discussed in the mailing list, this is implemented as an undocumented
>>> option.
>>
>> Maybe somebody wants to document it.
>
> Ah, I would gladly add the documentation, shall I write that it's an
> 'alternative' option similar to --pretty?

I do not think we want to introduce a new way to say the same thing for
the canned short options; "alternative" is not a good word for it.

Putting it in another way...

The output format is controlled by --pretty, which knows a set of canned
output formats.  You can specify --format=<fmt> if you want something
different from any of the canned format.  If your git does not support
this new notation, you can say --pretty=tformat:<fmt> to get the same
effect.  The old --pretty=tformat:<fmt> (and --pretty=format:<fmt>) is not
deprecated in any way.

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

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Felipe Contreras <felipe.contreras@gmail.com> writes:
> ...
>> Well, my hope was to replace --pretty=short with --format=short, but
>> you said that would break other scripts.
>
> It is not just scripts you break.  You also break people's trained
> fingers.
> ...
> The only reason why new --format=<fmt> could be an useful addition is
> because --pretty=format:<fmt> may be too long to type interactively.

An obvious alternative with lessor impact than your patch would be not to
introduce an additional option --format, but just make ":" as a synonym to
"tformat:".  Then you can say "--pretty=:%h %s".  You would need to type
one colon more but that might conceptually be less confusing, when
somebody is starting to learn git *after* this change, without knowing
that we did not have --format in earlier versions, from the documentation
and existing pages on various web sites.

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

[Felipe Contreras]

On Sun, Feb 22, 2009 at 7:53 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> On Sun, Feb 22, 2009 at 6:49 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>>
>>>> --format=:foo is a shorthand for --pretty=tformat:foo, otherwise this
>>>> new option acts just like --pretty=foo, except it's more intuitive for
>>>> users of 'git log'.
>>>
>>> It's been quite a long time since the earlier discussion, but I wonder why
>>> you need the colon before "foo" for this new shorthand.  I *think* you are
>>> also introducing "--format=short" as a synonym to "--pretty=short", but
>>> I do not think it is necessary.
>>
>> Well, my hope was to replace --pretty=short with --format=short, but
>> you said that would break other scripts.
>
> It is not just scripts you break.  You also break people's trained
> fingers.
>
> You can specify the kind of canned pretty printing with --pretty=short,
> and it is not any longer to type than --format.  For use in scripts that
> you write once and forget, there is no need to even apply this patch.
>
> The only reason why new --format=<fmt> could be an useful addition is
> because --pretty=format:<fmt> may be too long to type interactively.

That's not the main reason I suggested the change.

At least to me (and other people agreed on the original thread), when
I want to see the output of 'git log' in a different format the first
thing that pops into my mind is 'git log --format=foo'. The other
command I can recall right now that has something similar is 'find',
which has a 'printf' option, but 'find' can do much more than just
output stuff, like -delete, 'git log' on the other hand only prints
stuff, so --printf would not make sense, so only the f (format)
remains.

'git log --pretty=foo' is very unintuitive, no one would ever find
that option by intuition. Are there different kinds of pretties? Is
the default behavior --ugly?

Maybe 'git log --pretty' makes sense, but not 'git log --pretty=medium'.

>>>> As discussed in the mailing list, this is implemented as an undocumented
>>>> option.
>>>
>>> Maybe somebody wants to document it.
>>
>> Ah, I would gladly add the documentation, shall I write that it's an
>> 'alternative' option similar to --pretty?
>
> I do not think we want to introduce a new way to say the same thing for
> the canned short options; "alternative" is not a good word for it.
>
> Putting it in another way...
>
> The output format is controlled by --pretty, which knows a set of canned
> output formats.  You can specify --format=<fmt> if you want something
> different from any of the canned format.  If your git does not support
> this new notation, you can say --pretty=tformat:<fmt> to get the same
> effect.  The old --pretty=tformat:<fmt> (and --pretty=format:<fmt>) is not
> deprecated in any way.

Again, I don't see why 'canned format' == 'pretty' while 'custom
format' == 'format'. All this wording seems to suggest the canned
formats are pretty, while the custom formats are not.

I understand the option should be kept for people that are used to it,
but I don't think new users should suffer because of historic reasons.
And actually I believe many current users would not find
--pretty=email more natural than --format=email.

Cheers.

-- 
Felipe Contreras

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

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> I understand the option should be kept for people that are used to it,

It is not just that.  New people should learn existing lingo, as that is
the word used in the existing documentation and various random web pages,
so that they can use the same language when they teach people who are
newer than themselves.

If the existing word was not pretty (that came from "pretty-formatting")
but something unpronouncible like '--gzxfw=short", then your argument
might make some sense, but there is no such "breakage we need to fix"
here.

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

[Felipe Contreras]

On Sun, Feb 22, 2009 at 8:37 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> I understand the option should be kept for people that are used to it,
>
> It is not just that.  New people should learn existing lingo, as that is
> the word used in the existing documentation and various random web pages,
> so that they can use the same language when they teach people who are
> newer than themselves.

Yes, but the existing lingo is not perfect... I'm proposing this
particular lingo to be changed.

> If the existing word was not pretty (that came from "pretty-formatting")
> but something unpronouncible like '--gzxfw=short", then your argument
> might make some sense, but there is no such "breakage we need to fix"
> here.

It's not breakage that needs to be fixed, it's UI improvement, and one
guideline is that the interface needs to be intuitive and natural
(when possible). IMO pretty > gzxfw, but format > pretty. Don't you
think that --format=email is more natural than --pretty=email? I think
you are holding a bit too tight on the code reason why it's called
--pretty, but users shouldn't need to see the code in order to
understand why the naming of the options in git commands make sense.

-- 
Felipe Contreras

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

[Junio C Hamano]

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.

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

[Felipe Contreras]

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

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

[Felipe Contreras]

On Tue, Feb 24, 2009 at 2:56 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> 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.

People somehow got used to the ugly color, they'll get used to the
pretty one, in fact, they would probably like it better, and maybe
even thought more than once on changing it.

If they're the kind of people that don't like new things they'll
probably not be using git anyway.

-- 
Felipe Contreras

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

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

>>> 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.
>
> People somehow got used to the ugly color, they'll get used to the
> pretty one, in fact, they would probably like it better, and maybe
> even thought more than once on changing it.
>
> If they're the kind of people that don't like new things they'll
> probably not be using git anyway.

You do not have to send two messages in a row to reaffirm that you are of
irresponsible kind.  I heard you enough already.

Go away.

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

[Nanako Shiraishi]

Quoting Junio C Hamano <gitster@pobox.com>:

>
>>>> 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.
>>
>> People somehow got used to the ugly color, they'll get used to the
>> pretty one, in fact, they would probably like it better, and maybe
>> even thought more than once on changing it.
>>
>> If they're the kind of people that don't like new things they'll
>> probably not be using git anyway.
>
> You do not have to send two messages in a row to reaffirm that you are of
> irresponsible kind.  I heard you enough already.
>
> Go away.

Junio, what got into you?

I've always admired your calm and reasoned way to deal with even the most obnoxious people, and unlike more abrasive people on this list I've never seen you say "Go away" to anybody here.

Especially because I agree with you that calling pretty-printing as "pretty" isn't so broken to make such a big deal out of, it would be better not to chase a potentially useful contributor away on such a minor issue.

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

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

[Junio C Hamano]

Nanako Shiraishi <nanako3@lavabit.com> writes:

> Quoting Junio C Hamano <gitster@pobox.com>:
>
>>>>> 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.
>>>
>>> People somehow got used to the ugly color, they'll get used to the
>>> pretty one, in fact, they would probably like it better,...
>>
>> You do not have to send two messages in a row to reaffirm that you are of
>> irresponsible kind.  I heard you enough already.
>>
>> Go away.
>
> Junio, what got into you?
>
> I've always admired your calm and reasoned way to deal with even the
> most obnoxious people, and unlike more abrasive people on this list I've
> never seen you say "Go away" to anybody here.
>
> Especially because I agree with you that calling pretty-printing as
> "pretty" isn't so broken to make such a big deal out of, it would be
> better not to chase a potentially useful contributor away on such a
> minor issue.

I may try to be more diplomatic than other people, but it does not mean I
do not reserve the right to get annoyed enough from time to time.

When you hear people complain, and you take a poll and see there are many
people who agree with you, a naive thing to do is to assume that you now
got the majority vote.  Over time, you will learn that majority were
happy, were not complaining, and they merely did not bother to object to
the complainers who want to change things.  And the last thing you want is
to find these things out the hard way by bringing a sudden change to them
and giving them something to compalin about, like we did with 1.6.0.  You
need to learn to take "let's improve this thing, as many people want it"
with a huge grain of salt.

This cannot be stressed enough; if somebody is incapable of understanding
it, then we would be better off without him or her.

I am not so worried about losing Felipe as a contributor, not because I do
not think he is useful, but because I do not think he is stupid.

Judging from his other patches, I think he is reasonably capable and
intelligent, but just is not experienced enough with the culture around
here, especially about taking the existing users extremely seriously.  The
first patch landed in the git tree from him was in January 2009---perhaps
I should have tried to be more diplomatic with him as a newcomer for a bit
longer, but I am reasonably sure that he is smart enough to realize the
importance of different acceptance criteria between new features and
changes to existing interfaces after having time to think about it for a
few days, and will come back.

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

[Felipe Contreras]

On Tue, Feb 24, 2009 at 10:00 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Nanako Shiraishi <nanako3@lavabit.com> writes:
>
>> Quoting Junio C Hamano <gitster@pobox.com>:
>>
>>>>>> 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.
>>>>
>>>> People somehow got used to the ugly color, they'll get used to the
>>>> pretty one, in fact, they would probably like it better,...
>>>
>>> You do not have to send two messages in a row to reaffirm that you are of
>>> irresponsible kind.  I heard you enough already.
>>>
>>> Go away.
>>
>> Junio, what got into you?
>>
>> I've always admired your calm and reasoned way to deal with even the
>> most obnoxious people, and unlike more abrasive people on this list I've
>> never seen you say "Go away" to anybody here.
>>
>> Especially because I agree with you that calling pretty-printing as
>> "pretty" isn't so broken to make such a big deal out of, it would be
>> better not to chase a potentially useful contributor away on such a
>> minor issue.
>
> I may try to be more diplomatic than other people, but it does not mean I
> do not reserve the right to get annoyed enough from time to time.
>
> When you hear people complain, and you take a poll and see there are many
> people who agree with you, a naive thing to do is to assume that you now
> got the majority vote.  Over time, you will learn that majority were
> happy, were not complaining, and they merely did not bother to object to
> the complainers who want to change things.  And the last thing you want is
> to find these things out the hard way by bringing a sudden change to them
> and giving them something to compalin about, like we did with 1.6.0.  You
> need to learn to take "let's improve this thing, as many people want it"
> with a huge grain of salt.
>
> This cannot be stressed enough; if somebody is incapable of understanding
> it, then we would be better off without him or her.

I've discussed with many people regarding git; git-haters, people that
don't care about vcs, new git users, etc. So you might say that I have
an 'outsider' point of view, that shouldn't necessarily be a bad
thing.

The 'problems' about git that I've heard is that #1 lack of win32
support (now fixed), #2 complicated user interface (fixable), #3 lack
of storing renames (yes, people do complain about that). I don't
really care about #3, but I do care about #2.

Now, a google for 'git user interface' returns a few interesting
results, and one of them is Jon Loeliger asking for more grained
detail about the areas of improvement in the Git Survey, but somehow
nobody listened and now we don't have any nice graph about people
wanting UI improvements:
http://marc.info/?l=git&m=121691093706811&w=2

However, we do have comments in the survey about how to improve git:
 * #1 documentation #2 interface:  a. having tons of git-* binaries in
/usr/bin confuses tab-completion in the shell  b. the whole index
concept is a major pain point, i'm constantly trying to get around
having to deal with it
 * 1) CLI interface 2) More consistent terminology 3) Better
documentation with examples and use cases
 * a more intuitive command line interface
 * Better consistency of the interface. Documentation intended for
users, rather than being addressed to people who already understand
what a reflog is.
 * Better docs, better official interface
 * better docs, better usage hints, more consistent terminology/interface
 * Better user interface (on command line). More safety against user errors.
 * bzr like plugin ability, consistent interface with all commands as
well as consistent naming of commands.
 * cleaner interface, of course the docs could be better in places.
Better responsiveness: my buddy submitted a patch to add a "git svn
diff" command and received no response from the mailing list, either
positive or negative.
 * Cleaner, more consistent, easier to learn user interface.  Man
pages should be more user-oriented than developer-oriented.  Sparse
checkout can't come soon enough.
 * Cleanup the interface, not so many commands that do the same thing
or almost the same thing.
 * CLI user interface.  git-svn corrupts history if svn repository was
created according to instructions in the svn manual:
https://bugs.launchpad.net/ubuntu/+source/git-core/+bug/163341
Windows support is better than last year, but still causes problems
(especially with ssh keys and line-endings). We can't move to git from
svn until the Windows users are happy too.
...

And the list goes on and on.

One of the lessons learned from the switch from 'git-foo' is that the
change should have been more visible to users, a big annoying 'this is
deprecated' warning would have been more than enough, because that
will force users to shout if they don't like it or accept the
resolution once it's finally deprecated. Since can't possibly miss the
warning they would have no excuse to shout after the obsolescence.

I understand the "you can't change the status quo so easily kid"
argument, and I'm Ok with that. That's why I'm suggesting to deprecate
--pretty; users would still be able to use it but will receive a
warning. If as you say users are happy with --pretty, then they'll
shout when they realize someone is taking their precious option away,
we could wait until 1.8.0 to make it obsolete (remove it completely).

IMHO these kinds of improvements *need to be done*, even if they are
painful and take a lot of time. That doesn't mean 'git-foo' will be
repeated again; we can learn from the mistakes of the past.

Cheers.

-- 
Felipe Contreras

[PATCH] Add --format that is a synonym to --pretty

[Nanako Shiraishi]

Some people prefer to call the pretty-print styles "format", and get
annoyed to see "git log --format=short" fail.  Introduce it as a synonym
to --pretty so that both can be used interchangeably without breaking
examples in existing web pages or ppeople's expectations.

Having to say --format="format:%h %s" is redundant because none of the
predefined pretty-print styles have per-cent sign in it, so this patch
also makes it possible to say --pretty="%h %s" (and --format="%h %s").

Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---

I think doing it this way won't risk any compatibility issue.
Please be gentle; this is my first real patch in the C language.

 Documentation/pretty-formats.txt |    9 +++++++++
 Documentation/pretty-options.txt |    1 +
 pretty.c                         |   20 ++++++++++++++------
 revision.c                       |    2 +-
 4 files changed, 25 insertions(+), 7 deletions(-)

diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index 159390c..5c6e678 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -152,3 +152,12 @@ $ git log -2 --pretty=tformat:%h 4da45bef \
 4da45be
 7134973
 ---------------------
++
+In addition, any unrecognized string that has a `%` in it is interpreted
+as if it has `tformat:` in front of it.  For example, these two are
+equivalent:
++
+---------------------
+$ git log -2 --pretty=tformat:%h 4da45bef
+$ git log -2 --pretty=%h 4da45bef
+---------------------
diff --git a/Documentation/pretty-options.txt b/Documentation/pretty-options.txt
index 5f21efe..6596019 100644
--- a/Documentation/pretty-options.txt
+++ b/Documentation/pretty-options.txt
@@ -1,4 +1,5 @@
 --pretty[='<format>']::
+--format[='<format>']::
 
 	Pretty-print the contents of the commit logs in a given format,
 	where '<format>' can be one of 'oneline', 'short', 'medium',
diff --git a/pretty.c b/pretty.c
index 6cd9149..d739f6d 100644
--- a/pretty.c
+++ b/pretty.c
@@ -10,6 +10,15 @@
 
 static char *user_format;
 
+static void save_user_format(struct rev_info *rev, const char *cp, int is_tformat)
+{
+	free(user_format);
+	user_format = xstrdup(cp);
+	if (is_tformat)
+		rev->use_terminator = 1;
+	rev->commit_format = CMIT_FMT_USERFORMAT;
+}
+
 void get_commit_format(const char *arg, struct rev_info *rev)
 {
 	int i;
@@ -33,12 +42,7 @@ void get_commit_format(const char *arg, struct rev_info *rev)
 		return;
 	}
 	if (!prefixcmp(arg, "format:") || !prefixcmp(arg, "tformat:")) {
-		const char *cp = strchr(arg, ':') + 1;
-		free(user_format);
-		user_format = xstrdup(cp);
-		if (arg[0] == 't')
-			rev->use_terminator = 1;
-		rev->commit_format = CMIT_FMT_USERFORMAT;
+		save_user_format(rev, strchr(arg, ':') + 1, arg[0] == 't');
 		return;
 	}
 	for (i = 0; i < ARRAY_SIZE(cmt_fmts); i++) {
@@ -50,6 +54,10 @@ void get_commit_format(const char *arg, struct rev_info *rev)
 			return;
 		}
 	}
+	if (strchr(arg, '%')) {
+		save_user_format(rev, arg, 1);
+		return;
+	}
 
 	die("invalid --pretty format: %s", arg);
 }
diff --git a/revision.c b/revision.c
index 286e416..556c319 100644
--- a/revision.c
+++ b/revision.c
@@ -1144,7 +1144,7 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
 	} else if (!strcmp(arg, "--pretty")) {
 		revs->verbose_header = 1;
 		get_commit_format(arg+8, revs);
-	} else if (!prefixcmp(arg, "--pretty=")) {
+	} else if (!prefixcmp(arg, "--pretty=") || !prefixcmp(arg, "--format=")) {
 		revs->verbose_header = 1;
 		get_commit_format(arg+9, revs);
 	} else if (!strcmp(arg, "--graph")) {
-- 
1.6.2.rc1

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

Re: [PATCH] Add --format that is a synonym to --pretty

[Jeff King]

On Tue, Feb 24, 2009 at 01:06:26PM +0900, Nanako Shiraishi wrote:

> Some people prefer to call the pretty-print styles "format", and get
> annoyed to see "git log --format=short" fail.  Introduce it as a synonym
> to --pretty so that both can be used interchangeably without breaking
> examples in existing web pages or ppeople's expectations.

Thinking about this in context of the proposal to support --oneline (et
al), I think this part by itself gives confusing behavior. That is,
--pretty=oneline can be shortened to --oneline, but --pretty=format:$x
cannot be shortened to --format=$x.

But that is modified by what happens next:

> Having to say --format="format:%h %s" is redundant because none of the
> predefined pretty-print styles have per-cent sign in it, so this patch
> also makes it possible to say --pretty="%h %s" (and --format="%h %s").

This implies that --format=$x is equivalent to --pretty=format:$x, but
the patch actually implements the equivalent of --pretty=tformat:$x.

So that raises two concerns:

  1. We have to pick one as the "most common" for this shorthand; are we
     sure tformat is it? (Personally, I think it is, but I think it is a
     subtle point which we should be sure of).

  2. This _almost_ fixes the point I raised above. That is, --format=$x
     would match its longer --pretty=format:$x counterpart. Except that
     --format does _tformat_, which I would have expected to get via
     --tformat under such a proposal.

-Peff

Re: [PATCH] Add --format that is a synonym to --pretty

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Tue, Feb 24, 2009 at 01:06:26PM +0900, Nanako Shiraishi wrote:
>
>> Some people prefer to call the pretty-print styles "format", and get
>> annoyed to see "git log --format=short" fail.  Introduce it as a synonym
>> to --pretty so that both can be used interchangeably without breaking
>> examples in existing web pages or ppeople's expectations.
>
> Thinking about this in context of the proposal to support --oneline (et
> al), I think this part by itself gives confusing behavior. That is,
> --pretty=oneline can be shortened to --oneline, but --pretty=format:$x
> cannot be shortened to --format=$x.
>
> But that is modified by what happens next:
>
>> Having to say --format="format:%h %s" is redundant because none of the
>> predefined pretty-print styles have per-cent sign in it, so this patch
>> also makes it possible to say --pretty="%h %s" (and --format="%h %s").
>
> This implies that --format=$x is equivalent to --pretty=format:$x, but
> the patch actually implements the equivalent of --pretty=tformat:$x.
>
> So that raises two concerns:
>
>   1. We have to pick one as the "most common" for this shorthand; are we
>      sure tformat is it? (Personally, I think it is, but I think it is a
>      subtle point which we should be sure of).
>
>   2. This _almost_ fixes the point I raised above. That is, --format=$x
>      would match its longer --pretty=format:$x counterpart. Except that
>      --format does _tformat_, which I would have expected to get via
>      --tformat under such a proposal.

I think the patch suffers from the same problem Felipe's patch had, by
conflating two issues.  Because it had the ":some string with %" shorthand
support in addition to "--format is another way to spell --pretty", and it
did that only to "--format" side, I initially misunderstood Felipe's patch
as primarily addressing "Why do we have to say '--pretty=format:%h %s'
when it is obvious from the context that '%h %s' is a format".  It turns
out that he did not like "pretty" and wanted to be able to say "format"
even for the predefined pretty-print styles.

If we split this round into two patches, one that makes --format a synonym
to --pretty, and then another one that allows --{format,pretty}='%h %s',
and *stop there*, then we wouldn't have difficulties.

I do not think --oneline is a bad idea, but I do not think we should
explain it as "You can write anything that you can write after '--pretty='
without 'pretty=' and they mean the same thing".  That's where your
concern arises from.  You just say "'--pretty=oneline --abbrev-commit' is
so often used, so we have a shorthand for the whole thing: --oneline",
without implying anything about other things such as --short or --tformat.

Re: [PATCH] Add --format that is a synonym to --pretty

[Jeff King]

On Mon, Feb 23, 2009 at 09:33:59PM -0800, Junio C Hamano wrote:

> I think the patch suffers from the same problem Felipe's patch had, by
> conflating two issues.  Because it had the ":some string with %" shorthand

Yes, I totally agree they are two separate issues, and it should be two
patches.

> If we split this round into two patches, one that makes --format a synonym
> to --pretty, and then another one that allows --{format,pretty}='%h %s',
> and *stop there*, then we wouldn't have difficulties.

Right, and I am OK with that. I just wanted to make sure we were not
painting ourselves into a corner for a "patch 3/2" that has been
discussed.

> I do not think --oneline is a bad idea, but I do not think we should
> explain it as "You can write anything that you can write after '--pretty='
> without 'pretty=' and they mean the same thing".  That's where your
> concern arises from.  You just say "'--pretty=oneline --abbrev-commit' is
> so often used, so we have a shorthand for the whole thing: --oneline",
> without implying anything about other things such as --short or --tformat.

OK. I think that is reasonable. Personally, I would really only care
about --oneline, anyway (and I do think a --pretty=%h shorthand should
use "tformat"; the extra typing is probably not a big deal if you are
doing a big multi-line format).

-Peff

[PATCH 0/3] --format, --pretty and --oneline

[Nanako Shiraishi]

As suggested by Jeff and Junio, this splits my patch into two and
implements --oneline as a synonym for --pretty=oneline --abbrev-commit.

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

[PATCH 1/3] Add --format that is a synonym to --pretty

[Nanako Shiraishi]

Some people prefer to call the pretty-print styles "format", and get
annoyed to see "git log --format=short" fail.  Introduce it as a synonym
to --pretty so that both can be used.

Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
 Documentation/pretty-options.txt |    1 +
 revision.c                       |    2 +-
 2 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/Documentation/pretty-options.txt b/Documentation/pretty-options.txt
index 5f21efe..6596019 100644
--- a/Documentation/pretty-options.txt
+++ b/Documentation/pretty-options.txt
@@ -1,4 +1,5 @@
 --pretty[='<format>']::
+--format[='<format>']::
 
 	Pretty-print the contents of the commit logs in a given format,
 	where '<format>' can be one of 'oneline', 'short', 'medium',
diff --git a/revision.c b/revision.c
index 286e416..556c319 100644
--- a/revision.c
+++ b/revision.c
@@ -1144,7 +1144,7 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
 	} else if (!strcmp(arg, "--pretty")) {
 		revs->verbose_header = 1;
 		get_commit_format(arg+8, revs);
-	} else if (!prefixcmp(arg, "--pretty=")) {
+	} else if (!prefixcmp(arg, "--pretty=") || !prefixcmp(arg, "--format=")) {
 		revs->verbose_header = 1;
 		get_commit_format(arg+9, revs);
 	} else if (!strcmp(arg, "--graph")) {
-- 
1.6.2.rc1


-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

[PATCH 2/3] Give short-hands to --pretty=tformat:%formatstring

[Nanako Shiraishi]

Allow --pretty="%h %s" (and --format="%h %s") as shorthand for an often
used option --pretty=tformat:"%h %s".

Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
 Documentation/pretty-formats.txt |    9 +++++++++
 pretty.c                         |   20 ++++++++++++++------
 2 files changed, 23 insertions(+), 6 deletions(-)

diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index 159390c..5c6e678 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -152,3 +152,12 @@ $ git log -2 --pretty=tformat:%h 4da45bef \
 4da45be
 7134973
 ---------------------
++
+In addition, any unrecognized string that has a `%` in it is interpreted
+as if it has `tformat:` in front of it.  For example, these two are
+equivalent:
++
+---------------------
+$ git log -2 --pretty=tformat:%h 4da45bef
+$ git log -2 --pretty=%h 4da45bef
+---------------------
diff --git a/pretty.c b/pretty.c
index 6cd9149..d739f6d 100644
--- a/pretty.c
+++ b/pretty.c
@@ -10,6 +10,15 @@
 
 static char *user_format;
 
+static void save_user_format(struct rev_info *rev, const char *cp, int is_tformat)
+{
+	free(user_format);
+	user_format = xstrdup(cp);
+	if (is_tformat)
+		rev->use_terminator = 1;
+	rev->commit_format = CMIT_FMT_USERFORMAT;
+}
+
 void get_commit_format(const char *arg, struct rev_info *rev)
 {
 	int i;
@@ -33,12 +42,7 @@ void get_commit_format(const char *arg, struct rev_info *rev)
 		return;
 	}
 	if (!prefixcmp(arg, "format:") || !prefixcmp(arg, "tformat:")) {
-		const char *cp = strchr(arg, ':') + 1;
-		free(user_format);
-		user_format = xstrdup(cp);
-		if (arg[0] == 't')
-			rev->use_terminator = 1;
-		rev->commit_format = CMIT_FMT_USERFORMAT;
+		save_user_format(rev, strchr(arg, ':') + 1, arg[0] == 't');
 		return;
 	}
 	for (i = 0; i < ARRAY_SIZE(cmt_fmts); i++) {
@@ -50,6 +54,10 @@ void get_commit_format(const char *arg, struct rev_info *rev)
 			return;
 		}
 	}
+	if (strchr(arg, '%')) {
+		save_user_format(rev, arg, 1);
+		return;
+	}
 
 	die("invalid --pretty format: %s", arg);
 }
-- 
1.6.2.rc1

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

[PATCH 3/3] Add --oneline that is a synonym to "--pretty=oneline --abbrev-commit"

[Nanako Shiraishi]

These two are often used together but are too long to type.

Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
 Documentation/pretty-options.txt |    4 ++++
 revision.c                       |    4 ++++
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/Documentation/pretty-options.txt b/Documentation/pretty-options.txt
index 6596019..b0ea68a 100644
--- a/Documentation/pretty-options.txt
+++ b/Documentation/pretty-options.txt
@@ -18,6 +18,10 @@ configuration (see linkgit:git-config[1]).
 This should make "--pretty=oneline" a whole lot more readable for
 people using 80-column terminals.
 
+--oneline::
+	This is a shorthand for "--pretty=oneline --abbrev-commit"
+	used together.
+
 --encoding[=<encoding>]::
 	The commit objects record the encoding used for the log message
 	in their encoding header; this option can be used to tell the
diff --git a/revision.c b/revision.c
index 556c319..c4efe5b 100644
--- a/revision.c
+++ b/revision.c
@@ -1147,6 +1147,10 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
 	} else if (!prefixcmp(arg, "--pretty=") || !prefixcmp(arg, "--format=")) {
 		revs->verbose_header = 1;
 		get_commit_format(arg+9, revs);
+	} else if (!strcmp(arg, "--oneline")) {
+		revs->verbose_header = 1;
+		get_commit_format("oneline", revs);
+		revs->abbrev_commit = 1;
 	} else if (!strcmp(arg, "--graph")) {
 		revs->topo_order = 1;
 		revs->rewrite_parents = 1;
-- 
1.6.2.rc1

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

Re: [PATCH 3/3] Add --oneline that is a synonym to "--pretty=oneline --abbrev-commit"

[Junio C Hamano]

Nanako Shiraishi <nanako3@lavabit.com> writes:

> These two are often used together but are too long to type.
>
> Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
> ---
>  Documentation/pretty-options.txt |    4 ++++
>  revision.c                       |    4 ++++
>  2 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/pretty-options.txt b/Documentation/pretty-options.txt
> index 6596019..b0ea68a 100644
> --- a/Documentation/pretty-options.txt
> +++ b/Documentation/pretty-options.txt
> @@ -18,6 +18,10 @@ configuration (see linkgit:git-config[1]).
>  This should make "--pretty=oneline" a whole lot more readable for
>  people using 80-column terminals.
>  
> +--oneline::
> +	This is a shorthand for "--pretty=oneline --abbrev-commit"
> +	used together.
> +
>  --encoding[=<encoding>]::

The --pretty=oneline was one of the things I found that orthogonality
harmed usability in a big way.  Very nice.

I see Teemu already did bash completion for this series, and I'll take it
as an Aye.  Any volunteer who wants to add a few tests?

Thanks.

[PATCH] Add tests for git log --pretty, --format and --oneline.

[Felipe Contreras]

More specifically; --pretty=format, tformat and new %foo shortcut.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 t/t4202-log.sh |   40 ++++++++++++++++++++++++++++++++++++++++
 1 files changed, 40 insertions(+), 0 deletions(-)

diff --git a/t/t4202-log.sh b/t/t4202-log.sh
index 7b976ee..f1287fe 100755
--- a/t/t4202-log.sh
+++ b/t/t4202-log.sh
@@ -37,6 +37,46 @@ test_expect_success setup '
 
 '
 
+echo -ne "sixth\nfifth\nfourth\nthird\nsecond\ninitial" > expect
+test_expect_success 'pretty' '
+
+	git log --pretty="format:%s" > actual &&
+	test_cmp expect actual
+'
+
+echo -ne "sixth\nfifth\nfourth\nthird\nsecond\ninitial\n" > expect
+test_expect_success 'pretty (tformat)' '
+
+	git log --pretty="tformat:%s" > actual &&
+	test_cmp expect actual
+'
+
+test_expect_success 'pretty (shortcut)' '
+
+	git log --pretty="%s" > actual &&
+	test_cmp expect actual
+'
+
+test_expect_success 'format' '
+
+	git log --format="%s" > actual &&
+	test_cmp expect actual
+'
+
+cat > expect << EOF
+804a787 sixth
+394ef78 fifth
+5d31159 fourth
+2fbe8c0 third
+f7dab8e second
+3a2fdcb initial
+EOF
+test_expect_success 'oneline' '
+
+	git log --oneline > actual &&
+	test_cmp expect actual
+'
+
 test_expect_success 'diff-filter=A' '
 
 	actual=$(git log --pretty="format:%s" --diff-filter=A HEAD) &&
-- 
1.6.1.3

Re: [PATCH] Add tests for git log --pretty, --format and --oneline.

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> More specifically; --pretty=format, tformat and new %foo shortcut.
>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
>  t/t4202-log.sh |   40 ++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 40 insertions(+), 0 deletions(-)

Because 4202 seems to be about testing the log functionality and they rely
on correctly working format output to verify other aspects of the
operation of "git log", I initially was not sure if this is the right
place to add these new tests.  After looking around I didn't find any
existing test that checks the various --pretty output formats that the new
tests can be added, so this probably is as good a place as any.

> diff --git a/t/t4202-log.sh b/t/t4202-log.sh
> index 7b976ee..f1287fe 100755
> --- a/t/t4202-log.sh
> +++ b/t/t4202-log.sh
> @@ -37,6 +37,46 @@ test_expect_success setup '
>  
>  '
>  
> +echo -ne "sixth\nfifth\nfourth\nthird\nsecond\ninitial" > expect
> +test_expect_success 'pretty' '
> +
> +	git log --pretty="format:%s" > actual &&
> +	test_cmp expect actual
> +'
> +
> +echo -ne "sixth\nfifth\nfourth\nthird\nsecond\ninitial\n" > expect

We avoid "echo -e" to cater to people whose echo does not like it and
instead use printf for things like this.

Other than that, the patch looked Ok.  I queued it with a minor fixup.

Thanks.

Re: [PATCH] Add tests for git log --pretty, --format and --oneline.

[Jeff King]

On Wed, Feb 25, 2009 at 01:54:30AM -0800, Junio C Hamano wrote:

> Because 4202 seems to be about testing the log functionality and they rely
> on correctly working format output to verify other aspects of the
> operation of "git log", I initially was not sure if this is the right
> place to add these new tests.  After looking around I didn't find any
> existing test that checks the various --pretty output formats that the new
> tests can be added, so this probably is as good a place as any.

t6006?

-Peff

Re: [PATCH] Add tests for git log --pretty, --format and --oneline.

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Wed, Feb 25, 2009 at 01:54:30AM -0800, Junio C Hamano wrote:
>
>> Because 4202 seems to be about testing the log functionality and they rely
>> on correctly working format output to verify other aspects of the
>> operation of "git log", I initially was not sure if this is the right
>> place to add these new tests.  After looking around I didn't find any
>> existing test that checks the various --pretty output formats that the new
>> tests can be added, so this probably is as good a place as any.
>
> t6006?

Good eyes.  But sorry I've already queued the four patches to 'next' and
pushed the result out.  It probably is not worth moving the tests between
two files as a follow-up patch.

Re: [PATCH] Add tests for git log --pretty, --format and --oneline.

[Jeff King]

On Wed, Feb 25, 2009 at 02:16:40AM -0800, Junio C Hamano wrote:

> >> Because 4202 seems to be about testing the log functionality and they rely
> >> on correctly working format output to verify other aspects of the
> >> operation of "git log", I initially was not sure if this is the right
> >> place to add these new tests.  After looking around I didn't find any
> >> existing test that checks the various --pretty output formats that the new
> >> tests can be added, so this probably is as good a place as any.
> >
> > t6006?
> 
> Good eyes.  But sorry I've already queued the four patches to 'next' and
> pushed the result out.  It probably is not worth moving the tests between
> two files as a follow-up patch.

Good memory; I wrote t6006. ;)

I don't think it is a big deal. I actually thought of it when I read the
original patch but decided not to say anything. t6006 is really about
exercising the formats themselves, so you could argue that the new tests
go just as well in either spot.

-Peff

[PATCH] bash completion: add --format= and --oneline options for "git log"

[Teemu Likonen]

Signed-off-by: Teemu Likonen <tlikonen@iki.fi>
---

I like this change and would immediately switch to using --format= and
--oneline instead of --pretty=. I think we should add these bash
completions too.


 contrib/completion/git-completion.bash |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 0a3092f..34396c2 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1012,10 +1012,15 @@ _git_log ()
 	--pretty=*)
 		__gitcomp "$__git_log_pretty_formats
 			" "" "${cur##--pretty=}"
 		return
 		;;
+	--format=*)
+		__gitcomp "$__git_log_pretty_formats
+			" "" "${cur##--format=}"
+		return
+		;;
 	--date=*)
 		__gitcomp "
 			relative iso8601 rfc2822 short local default
 		" "" "${cur##--date=}"
 		return
@@ -1028,10 +1033,12 @@ _git_log ()
 			--root --topo-order --date-order --reverse
 			--follow
 			--abbrev-commit --abbrev=
 			--relative-date --date=
 			--pretty=
+			--format=
+			--oneline
 			--cherry-pick
 			--graph
 			--decorate
 			--walk-reflogs
 			--parents --children
-- 
1.6.2.rc1.29.g79ccf

[PATCH v2] bash completion: add --format= and --oneline options for "git log"

[Teemu Likonen]

We also add --format= completion for "git show".

Signed-off-by: Teemu Likonen <tlikonen@iki.fi>
---

On 2009-02-24 13:02 (+0200), Teemu Likonen wrote:

> I like this change and would immediately switch to using --format= and
> --oneline instead of --pretty=. I think we should add these bash
> completions too.

And let's add --format= completion for "git show" too. I think --oneline
completion is not needed with "git show" even though it works.

This patch replaces my previous one.



 contrib/completion/git-completion.bash |   14 ++++++++++++--
 1 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 0a3092f..31608cb 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1012,10 +1012,15 @@ _git_log ()
 	--pretty=*)
 		__gitcomp "$__git_log_pretty_formats
 			" "" "${cur##--pretty=}"
 		return
 		;;
+	--format=*)
+		__gitcomp "$__git_log_pretty_formats
+			" "" "${cur##--format=}"
+		return
+		;;
 	--date=*)
 		__gitcomp "
 			relative iso8601 rfc2822 short local default
 		" "" "${cur##--date=}"
 		return
@@ -1027,11 +1032,11 @@ _git_log ()
 			$__git_log_gitk_options
 			--root --topo-order --date-order --reverse
 			--follow
 			--abbrev-commit --abbrev=
 			--relative-date --date=
-			--pretty=
+			--pretty= --format= --oneline
 			--cherry-pick
 			--graph
 			--decorate
 			--walk-reflogs
 			--parents --children
@@ -1539,12 +1544,17 @@ _git_show ()
 	--pretty=*)
 		__gitcomp "$__git_log_pretty_formats
 			" "" "${cur##--pretty=}"
 		return
 		;;
+	--format=*)
+		__gitcomp "$__git_log_pretty_formats
+			" "" "${cur##--format=}"
+		return
+		;;
 	--*)
-		__gitcomp "--pretty=
+		__gitcomp "--pretty= --format=
 			$__git_diff_common_options
 			"
 		return
 		;;
 	esac
-- 
1.6.2.rc1.29.g79ccf

Re: [PATCH v2] bash completion: add --format= and --oneline options for "git log"

[Shawn O. Pearce]

Teemu Likonen <tlikonen@iki.fi> wrote:
> We also add --format= completion for "git show".
> 
> Signed-off-by: Teemu Likonen <tlikonen@iki.fi>
> ---
> 
> On 2009-02-24 13:02 (+0200), Teemu Likonen wrote:
> 
> > I like this change and would immediately switch to using --format= and
> > --oneline instead of --pretty=. I think we should add these bash
> > completions too.
> 
> And let's add --format= completion for "git show" too. I think --oneline
> completion is not needed with "git show" even though it works.

What version of git supports "git log --format" ?

'cause I can't find evidence that it is implemented in any current
version that Junio would apply this patch to.
 
-- 
Shawn.

Re: [PATCH v2] bash completion: add --format= and --oneline options for "git log"

[Teemu Likonen]

On 2009-02-24 07:39 (-0800), Shawn O. Pearce wrote:

> Teemu Likonen <tlikonen@iki.fi> wrote:
>> On 2009-02-24 13:02 (+0200), Teemu Likonen wrote:
>> 
>> > I like this change and would immediately switch to using --format= and
>> > --oneline instead of --pretty=. I think we should add these bash
>> > completions too.
>> 
>> And let's add --format= completion for "git show" too. I think --oneline
>> completion is not needed with "git show" even though it works.
>
> What version of git supports "git log --format" ?
>
> 'cause I can't find evidence that it is implemented in any current
> version that Junio would apply this patch to.

This is meant to be a part of Nanako's patch series:

    http://thread.gmane.org/gmane.comp.version-control.git/111278

Re: [PATCH v2] bash completion: add --format= and --oneline options for "git log"

[Shawn O. Pearce]

Teemu Likonen <tlikonen@iki.fi> wrote:
> On 2009-02-24 07:39 (-0800), Shawn O. Pearce wrote:
> >
> > What version of git supports "git log --format" ?
> >
> > 'cause I can't find evidence that it is implemented in any current
> > version that Junio would apply this patch to.
> 
> This is meant to be a part of Nanako's patch series:
> 
>     http://thread.gmane.org/gmane.comp.version-control.git/111278

Oh, sorry.  I don't use a threaded client so I missed the
fact this was attached to her series.

Looks good to me.

Acked-by: Shawn O. Pearce <spearce@spearce.org>

-- 
Shawn.

Re: [PATCH v2] bash completion: add --format= and --oneline options for "git log"

[Teemu Likonen]

On 2009-02-24 07:57 (-0800), Shawn O. Pearce wrote:

> Teemu Likonen <tlikonen@iki.fi> wrote:
>> This is meant to be a part of Nanako's patch series:
>> 
>>     http://thread.gmane.org/gmane.comp.version-control.git/111278
>
> Oh, sorry.  I don't use a threaded client so I missed the
> fact this was attached to her series.

I'm sorry too. That was a good lesson why I should provide enough
context (Gmane link for example) when adding CCs.

Re: [PATCH v2] bash completion: add --format= and --oneline options for "git log"

[Teemu Likonen]

On 2009-02-24 15:33 (+0200), Teemu Likonen wrote:

> We also add --format= completion for "git show".
>
> Signed-off-by: Teemu Likonen <tlikonen@iki.fi>
> ---

>  contrib/completion/git-completion.bash |   14 ++++++++++++--
>  1 files changed, 12 insertions(+), 2 deletions(-)

ns/pretty-format topic got merged to "next" (e7a7e8a) but my bash
completion patch didn't go there. Is there a specific reason for that?
The patch was acked by Shawn.

The thread is here:

http://thread.gmane.org/gmane.comp.version-control.git/110962/focus=111286

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

[Felipe Contreras]

On Tue, Feb 24, 2009 at 3:33 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>>>> 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.
>>
>> People somehow got used to the ugly color, they'll get used to the
>> pretty one, in fact, they would probably like it better, and maybe
>> even thought more than once on changing it.
>>
>> If they're the kind of people that don't like new things they'll
>> probably not be using git anyway.
>
> You do not have to send two messages in a row to reaffirm that you are of
> irresponsible kind.  I heard you enough already.
>
> Go away.

After sending the email I realized I didn't answer your argument about
people already used to the existing stuff.

I might sound too aggressive on email, but my intention is not to
attack anything or anybody, just improve things.

-- 
Felipe Contreras

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

[Linus Torvalds]

On Sun, 22 Feb 2009, Felipe Contreras wrote:
>
> 'git log --pretty=foo' is very unintuitive, no one would ever find
> that option by intuition. Are there different kinds of pretties? Is
> the default behavior --ugly?

Historically, the default behaviour _was_ indeed --ugly.

There was no native "git log" command per se, it was literally a script 
that did something like

	git-rev-list <rev-opts> |
		git-diff-tree --stdin --pretty |
		$(PAGER)

and the "--pretty" option was to tell git to give human-readable output 
from git-diff-tree rather than the harsh raw stuff.

So yes, the default for git used to be "low-level plumbing commands for 
scripting", with some options to turn them pretty for the fleshies.

Then we started having more options, so "--pretty" became "--pretty=xyz".

But I do realize that without the historical background, none of this 
makes sense. And quite frankly, I do hate "--pretty=xyz" myself. I find 
myself wishing I could just write

	git log --oneline

instead of "--pretty=oneline", and I wish "shortlog" was a pretty format 
instead of a command of its own.

So at least personally, I would not object AT ALL to

 - leave the "--pretty=xyz" parsing for historical reasons

 - support "--format=xyz" too, because it does make sense (and it's 
   unambiguous: a format without a '%' sign in it makes no sense, so there 
   is no reason to have "--format=format:%s"

 - if we see an unrecognized "--<option>", and the <option> is a format 
   name, just assume the user was lazy and couldn't be bothered to write 
   out "format="

and then for extra bonus points, make "shortlog" work as a format too.

			Linus

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

[Jakub Narebski]

Linus Torvalds <torvalds@linux-foundation.org> writes:

[...]

> and then for extra bonus points, make "shortlog" work as a format too.

Well, shortlog is a bit different as it reorders and summarizes log
information.  But if --stat is format of diff, then I guess shortlog
(future log --format=summary) is a format for log...

-- 
Jakub Narebski
Poland
ShadeHawk on #git

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

[Wincent Colaiuta]

El 22/2/2009, a las 21:34, Linus Torvalds escribió:

> But I do realize that without the historical background, none of this
> makes sense. And quite frankly, I do hate "--pretty=xyz" myself. I  
> find
> myself wishing I could just write
>
> 	git log --oneline
>
> instead of "--pretty=oneline", and I wish "shortlog" was a pretty  
> format
> instead of a command of its own.


Why not an alias then?

	git oneline

ie. something like this, which I have in my config:

	alias.oneline=log --pretty=oneline --abbrev-commit

Cheers,
Wincent