* [RFC/PATCH] revision.c: add --format option for 'git log' @ 2009-02-21 15:26 Felipe Contreras 2009-02-22 16:49 ` Junio C Hamano 0 siblings, 1 reply; 40+ messages in thread From: Felipe Contreras @ 2009-02-21 15:26 UTC (permalink / raw) To: git; +Cc: 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 ^ permalink raw reply related [flat|nested] 40+ messages in thread
* Re: [RFC/PATCH] revision.c: add --format option for 'git log' 2009-02-21 15:26 [RFC/PATCH] revision.c: add --format option for 'git log' Felipe Contreras @ 2009-02-22 16:49 ` Junio C Hamano 2009-02-22 17:18 ` Felipe Contreras 0 siblings, 1 reply; 40+ messages in thread From: Junio C Hamano @ 2009-02-22 16:49 UTC (permalink / raw) To: Felipe Contreras; +Cc: git 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC/PATCH] revision.c: add --format option for 'git log' 2009-02-22 16:49 ` Junio C Hamano @ 2009-02-22 17:18 ` Felipe Contreras 2009-02-22 17:53 ` Junio C Hamano 0 siblings, 1 reply; 40+ messages in thread From: Felipe Contreras @ 2009-02-22 17:18 UTC (permalink / raw) To: Junio C Hamano; +Cc: git 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC/PATCH] revision.c: add --format option for 'git log' 2009-02-22 17:18 ` Felipe Contreras @ 2009-02-22 17:53 ` Junio C Hamano 2009-02-22 18:06 ` Junio C Hamano 2009-02-22 18:14 ` Felipe Contreras 0 siblings, 2 replies; 40+ messages in thread From: Junio C Hamano @ 2009-02-22 17:53 UTC (permalink / raw) To: Felipe Contreras; +Cc: git 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC/PATCH] revision.c: add --format option for 'git log' 2009-02-22 17:53 ` Junio C Hamano @ 2009-02-22 18:06 ` Junio C Hamano 2009-02-22 18:14 ` Felipe Contreras 1 sibling, 0 replies; 40+ messages in thread From: Junio C Hamano @ 2009-02-22 18:06 UTC (permalink / raw) To: Felipe Contreras; +Cc: git 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC/PATCH] revision.c: add --format option for 'git log' 2009-02-22 17:53 ` Junio C Hamano 2009-02-22 18:06 ` Junio C Hamano @ 2009-02-22 18:14 ` Felipe Contreras 2009-02-22 18:37 ` Junio C Hamano 2009-02-22 20:34 ` Linus Torvalds 1 sibling, 2 replies; 40+ messages in thread From: Felipe Contreras @ 2009-02-22 18:14 UTC (permalink / raw) To: Junio C Hamano; +Cc: git 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC/PATCH] revision.c: add --format option for 'git log' 2009-02-22 18:14 ` Felipe Contreras @ 2009-02-22 18:37 ` Junio C Hamano 2009-02-22 18:55 ` Felipe Contreras 2009-02-22 20:34 ` Linus Torvalds 1 sibling, 1 reply; 40+ messages in thread From: Junio C Hamano @ 2009-02-22 18:37 UTC (permalink / raw) To: Felipe Contreras; +Cc: git 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC/PATCH] revision.c: add --format option for 'git log' 2009-02-22 18:37 ` Junio C Hamano @ 2009-02-22 18:55 ` Felipe Contreras 2009-02-23 6:39 ` Junio C Hamano 0 siblings, 1 reply; 40+ messages in thread From: Felipe Contreras @ 2009-02-22 18:55 UTC (permalink / raw) To: Junio C Hamano; +Cc: git 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC/PATCH] revision.c: add --format option for 'git log' 2009-02-22 18:55 ` Felipe Contreras @ 2009-02-23 6:39 ` Junio C Hamano 2009-02-24 0:56 ` Felipe Contreras 0 siblings, 1 reply; 40+ messages in thread From: Junio C Hamano @ 2009-02-23 6:39 UTC (permalink / raw) To: Felipe Contreras; +Cc: git 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC/PATCH] revision.c: add --format option for 'git log' 2009-02-23 6:39 ` Junio C Hamano @ 2009-02-24 0:56 ` Felipe Contreras 2009-02-24 1:03 ` Felipe Contreras 0 siblings, 1 reply; 40+ messages in thread From: Felipe Contreras @ 2009-02-24 0:56 UTC (permalink / raw) To: Junio C Hamano; +Cc: git 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC/PATCH] revision.c: add --format option for 'git log' 2009-02-24 0:56 ` Felipe Contreras @ 2009-02-24 1:03 ` Felipe Contreras 2009-02-24 1:33 ` Junio C Hamano 0 siblings, 1 reply; 40+ messages in thread From: Felipe Contreras @ 2009-02-24 1:03 UTC (permalink / raw) To: Junio C Hamano; +Cc: git 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC/PATCH] revision.c: add --format option for 'git log' 2009-02-24 1:03 ` Felipe Contreras @ 2009-02-24 1:33 ` Junio C Hamano 2009-02-24 1:55 ` Nanako Shiraishi ` (2 more replies) 0 siblings, 3 replies; 40+ messages in thread From: Junio C Hamano @ 2009-02-24 1:33 UTC (permalink / raw) To: Felipe Contreras; +Cc: git 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC/PATCH] revision.c: add --format option for 'git log' 2009-02-24 1:33 ` Junio C Hamano @ 2009-02-24 1:55 ` Nanako Shiraishi 2009-02-24 8:00 ` Junio C Hamano 2009-02-24 4:06 ` [PATCH] Add --format that is a synonym to --pretty Nanako Shiraishi 2009-02-24 8:35 ` [RFC/PATCH] revision.c: add --format option for 'git log' Felipe Contreras 2 siblings, 1 reply; 40+ messages in thread From: Nanako Shiraishi @ 2009-02-24 1:55 UTC (permalink / raw) To: Junio C Hamano; +Cc: felipe.contreras, git 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/ ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC/PATCH] revision.c: add --format option for 'git log' 2009-02-24 1:55 ` Nanako Shiraishi @ 2009-02-24 8:00 ` Junio C Hamano 2009-02-24 9:34 ` Felipe Contreras 0 siblings, 1 reply; 40+ messages in thread From: Junio C Hamano @ 2009-02-24 8:00 UTC (permalink / raw) To: Nanako Shiraishi; +Cc: git 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC/PATCH] revision.c: add --format option for 'git log' 2009-02-24 8:00 ` Junio C Hamano @ 2009-02-24 9:34 ` Felipe Contreras 0 siblings, 0 replies; 40+ messages in thread From: Felipe Contreras @ 2009-02-24 9:34 UTC (permalink / raw) To: Junio C Hamano; +Cc: Nanako Shiraishi, git 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* [PATCH] Add --format that is a synonym to --pretty 2009-02-24 1:33 ` Junio C Hamano 2009-02-24 1:55 ` Nanako Shiraishi @ 2009-02-24 4:06 ` Nanako Shiraishi 2009-02-24 4:50 ` Jeff King 2009-02-24 8:35 ` [RFC/PATCH] revision.c: add --format option for 'git log' Felipe Contreras 2 siblings, 1 reply; 40+ messages in thread From: Nanako Shiraishi @ 2009-02-24 4:06 UTC (permalink / raw) To: Junio C Hamano; +Cc: felipe.contreras, git 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/ ^ permalink raw reply related [flat|nested] 40+ messages in thread
* Re: [PATCH] Add --format that is a synonym to --pretty 2009-02-24 4:06 ` [PATCH] Add --format that is a synonym to --pretty Nanako Shiraishi @ 2009-02-24 4:50 ` Jeff King 2009-02-24 5:33 ` Junio C Hamano 0 siblings, 1 reply; 40+ messages in thread From: Jeff King @ 2009-02-24 4:50 UTC (permalink / raw) To: Nanako Shiraishi; +Cc: Junio C Hamano, felipe.contreras, git 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH] Add --format that is a synonym to --pretty 2009-02-24 4:50 ` Jeff King @ 2009-02-24 5:33 ` Junio C Hamano 2009-02-24 5:45 ` Jeff King 0 siblings, 1 reply; 40+ messages in thread From: Junio C Hamano @ 2009-02-24 5:33 UTC (permalink / raw) To: Jeff King; +Cc: Nanako Shiraishi, felipe.contreras, git 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH] Add --format that is a synonym to --pretty 2009-02-24 5:33 ` Junio C Hamano @ 2009-02-24 5:45 ` Jeff King 2009-02-24 9:59 ` [PATCH 0/3] --format, --pretty and --oneline Nanako Shiraishi 0 siblings, 1 reply; 40+ messages in thread From: Jeff King @ 2009-02-24 5:45 UTC (permalink / raw) To: Junio C Hamano; +Cc: Nanako Shiraishi, felipe.contreras, git 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* [PATCH 0/3] --format, --pretty and --oneline 2009-02-24 5:45 ` Jeff King @ 2009-02-24 9:59 ` Nanako Shiraishi 2009-02-24 9:59 ` [PATCH 1/3] Add --format that is a synonym to --pretty Nanako Shiraishi ` (3 more replies) 0 siblings, 4 replies; 40+ messages in thread From: Nanako Shiraishi @ 2009-02-24 9:59 UTC (permalink / raw) To: git; +Cc: Jeff King, Junio C Hamano, felipe.contreras 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/ ^ permalink raw reply [flat|nested] 40+ messages in thread
* [PATCH 1/3] Add --format that is a synonym to --pretty 2009-02-24 9:59 ` [PATCH 0/3] --format, --pretty and --oneline Nanako Shiraishi @ 2009-02-24 9:59 ` Nanako Shiraishi 2009-02-24 9:59 ` [PATCH 2/3] Give short-hands to --pretty=tformat:%formatstring Nanako Shiraishi ` (2 subsequent siblings) 3 siblings, 0 replies; 40+ messages in thread From: Nanako Shiraishi @ 2009-02-24 9:59 UTC (permalink / raw) To: git 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/ ^ permalink raw reply related [flat|nested] 40+ messages in thread
* [PATCH 2/3] Give short-hands to --pretty=tformat:%formatstring 2009-02-24 9:59 ` [PATCH 0/3] --format, --pretty and --oneline Nanako Shiraishi 2009-02-24 9:59 ` [PATCH 1/3] Add --format that is a synonym to --pretty Nanako Shiraishi @ 2009-02-24 9:59 ` Nanako Shiraishi 2009-02-24 9:59 ` [PATCH 3/3] Add --oneline that is a synonym to "--pretty=oneline --abbrev-commit" Nanako Shiraishi 2009-02-24 11:02 ` [PATCH] bash completion: add --format= and --oneline options for "git log" Teemu Likonen 3 siblings, 0 replies; 40+ messages in thread From: Nanako Shiraishi @ 2009-02-24 9:59 UTC (permalink / raw) To: git 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/ ^ permalink raw reply related [flat|nested] 40+ messages in thread
* [PATCH 3/3] Add --oneline that is a synonym to "--pretty=oneline --abbrev-commit" 2009-02-24 9:59 ` [PATCH 0/3] --format, --pretty and --oneline Nanako Shiraishi 2009-02-24 9:59 ` [PATCH 1/3] Add --format that is a synonym to --pretty Nanako Shiraishi 2009-02-24 9:59 ` [PATCH 2/3] Give short-hands to --pretty=tformat:%formatstring Nanako Shiraishi @ 2009-02-24 9:59 ` Nanako Shiraishi 2009-02-24 17:38 ` Junio C Hamano 2009-02-24 11:02 ` [PATCH] bash completion: add --format= and --oneline options for "git log" Teemu Likonen 3 siblings, 1 reply; 40+ messages in thread From: Nanako Shiraishi @ 2009-02-24 9:59 UTC (permalink / raw) To: git 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/ ^ permalink raw reply related [flat|nested] 40+ messages in thread
* Re: [PATCH 3/3] Add --oneline that is a synonym to "--pretty=oneline --abbrev-commit" 2009-02-24 9:59 ` [PATCH 3/3] Add --oneline that is a synonym to "--pretty=oneline --abbrev-commit" Nanako Shiraishi @ 2009-02-24 17:38 ` Junio C Hamano 2009-02-24 21:06 ` [PATCH] Add tests for git log --pretty, --format and --oneline Felipe Contreras 0 siblings, 1 reply; 40+ messages in thread From: Junio C Hamano @ 2009-02-24 17:38 UTC (permalink / raw) To: Nanako Shiraishi; +Cc: git 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* [PATCH] Add tests for git log --pretty, --format and --oneline. 2009-02-24 17:38 ` Junio C Hamano @ 2009-02-24 21:06 ` Felipe Contreras 2009-02-25 9:54 ` Junio C Hamano 0 siblings, 1 reply; 40+ messages in thread From: Felipe Contreras @ 2009-02-24 21:06 UTC (permalink / raw) To: git; +Cc: Junio C Hamano, Nanako Shiraishi, 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 ^ permalink raw reply related [flat|nested] 40+ messages in thread
* Re: [PATCH] Add tests for git log --pretty, --format and --oneline. 2009-02-24 21:06 ` [PATCH] Add tests for git log --pretty, --format and --oneline Felipe Contreras @ 2009-02-25 9:54 ` Junio C Hamano 2009-02-25 9:57 ` Jeff King 0 siblings, 1 reply; 40+ messages in thread From: Junio C Hamano @ 2009-02-25 9:54 UTC (permalink / raw) To: Felipe Contreras; +Cc: git, Nanako Shiraishi 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH] Add tests for git log --pretty, --format and --oneline. 2009-02-25 9:54 ` Junio C Hamano @ 2009-02-25 9:57 ` Jeff King 2009-02-25 10:16 ` Junio C Hamano 0 siblings, 1 reply; 40+ messages in thread From: Jeff King @ 2009-02-25 9:57 UTC (permalink / raw) To: Junio C Hamano; +Cc: Felipe Contreras, git, Nanako Shiraishi 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH] Add tests for git log --pretty, --format and --oneline. 2009-02-25 9:57 ` Jeff King @ 2009-02-25 10:16 ` Junio C Hamano 2009-02-25 10:20 ` Jeff King 0 siblings, 1 reply; 40+ messages in thread From: Junio C Hamano @ 2009-02-25 10:16 UTC (permalink / raw) To: Jeff King; +Cc: Felipe Contreras, git, Nanako Shiraishi 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH] Add tests for git log --pretty, --format and --oneline. 2009-02-25 10:16 ` Junio C Hamano @ 2009-02-25 10:20 ` Jeff King 0 siblings, 0 replies; 40+ messages in thread From: Jeff King @ 2009-02-25 10:20 UTC (permalink / raw) To: Junio C Hamano; +Cc: Felipe Contreras, git, Nanako Shiraishi 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* [PATCH] bash completion: add --format= and --oneline options for "git log" 2009-02-24 9:59 ` [PATCH 0/3] --format, --pretty and --oneline Nanako Shiraishi ` (2 preceding siblings ...) 2009-02-24 9:59 ` [PATCH 3/3] Add --oneline that is a synonym to "--pretty=oneline --abbrev-commit" Nanako Shiraishi @ 2009-02-24 11:02 ` Teemu Likonen 2009-02-24 13:33 ` [PATCH v2] " Teemu Likonen 3 siblings, 1 reply; 40+ messages in thread From: Teemu Likonen @ 2009-02-24 11:02 UTC (permalink / raw) To: Nanako Shiraishi Cc: git, Jeff King, Junio C Hamano, felipe.contreras, Shawn O. Pearce 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 ^ permalink raw reply related [flat|nested] 40+ messages in thread
* [PATCH v2] bash completion: add --format= and --oneline options for "git log" 2009-02-24 11:02 ` [PATCH] bash completion: add --format= and --oneline options for "git log" Teemu Likonen @ 2009-02-24 13:33 ` Teemu Likonen 2009-02-24 15:39 ` Shawn O. Pearce 2009-02-27 18:53 ` Teemu Likonen 0 siblings, 2 replies; 40+ messages in thread From: Teemu Likonen @ 2009-02-24 13:33 UTC (permalink / raw) To: Nanako Shiraishi Cc: git, Jeff King, Junio C Hamano, felipe.contreras, Shawn O. Pearce 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 ^ permalink raw reply related [flat|nested] 40+ messages in thread
* Re: [PATCH v2] bash completion: add --format= and --oneline options for "git log" 2009-02-24 13:33 ` [PATCH v2] " Teemu Likonen @ 2009-02-24 15:39 ` Shawn O. Pearce 2009-02-24 15:47 ` Teemu Likonen 2009-02-27 18:53 ` Teemu Likonen 1 sibling, 1 reply; 40+ messages in thread From: Shawn O. Pearce @ 2009-02-24 15:39 UTC (permalink / raw) To: Teemu Likonen Cc: Nanako Shiraishi, git, Jeff King, Junio C Hamano, felipe.contreras 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH v2] bash completion: add --format= and --oneline options for "git log" 2009-02-24 15:39 ` Shawn O. Pearce @ 2009-02-24 15:47 ` Teemu Likonen 2009-02-24 15:57 ` Shawn O. Pearce 0 siblings, 1 reply; 40+ messages in thread From: Teemu Likonen @ 2009-02-24 15:47 UTC (permalink / raw) To: Shawn O. Pearce Cc: Nanako Shiraishi, git, Jeff King, Junio C Hamano, felipe.contreras 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH v2] bash completion: add --format= and --oneline options for "git log" 2009-02-24 15:47 ` Teemu Likonen @ 2009-02-24 15:57 ` Shawn O. Pearce 2009-02-24 16:14 ` Teemu Likonen 0 siblings, 1 reply; 40+ messages in thread From: Shawn O. Pearce @ 2009-02-24 15:57 UTC (permalink / raw) To: Teemu Likonen Cc: Nanako Shiraishi, git, Jeff King, Junio C Hamano, felipe.contreras 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH v2] bash completion: add --format= and --oneline options for "git log" 2009-02-24 15:57 ` Shawn O. Pearce @ 2009-02-24 16:14 ` Teemu Likonen 0 siblings, 0 replies; 40+ messages in thread From: Teemu Likonen @ 2009-02-24 16:14 UTC (permalink / raw) To: Shawn O. Pearce Cc: Nanako Shiraishi, git, Jeff King, Junio C Hamano, felipe.contreras 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH v2] bash completion: add --format= and --oneline options for "git log" 2009-02-24 13:33 ` [PATCH v2] " Teemu Likonen 2009-02-24 15:39 ` Shawn O. Pearce @ 2009-02-27 18:53 ` Teemu Likonen 1 sibling, 0 replies; 40+ messages in thread From: Teemu Likonen @ 2009-02-27 18:53 UTC (permalink / raw) To: Junio C Hamano; +Cc: git, Shawn O. Pearce 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC/PATCH] revision.c: add --format option for 'git log' 2009-02-24 1:33 ` Junio C Hamano 2009-02-24 1:55 ` Nanako Shiraishi 2009-02-24 4:06 ` [PATCH] Add --format that is a synonym to --pretty Nanako Shiraishi @ 2009-02-24 8:35 ` Felipe Contreras 2 siblings, 0 replies; 40+ messages in thread From: Felipe Contreras @ 2009-02-24 8:35 UTC (permalink / raw) To: Junio C Hamano; +Cc: git 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC/PATCH] revision.c: add --format option for 'git log' 2009-02-22 18:14 ` Felipe Contreras 2009-02-22 18:37 ` Junio C Hamano @ 2009-02-22 20:34 ` Linus Torvalds 2009-02-22 22:12 ` Jakub Narebski 2009-02-23 9:55 ` Wincent Colaiuta 1 sibling, 2 replies; 40+ messages in thread From: Linus Torvalds @ 2009-02-22 20:34 UTC (permalink / raw) To: Felipe Contreras; +Cc: Junio C Hamano, Git Mailing List 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC/PATCH] revision.c: add --format option for 'git log' 2009-02-22 20:34 ` Linus Torvalds @ 2009-02-22 22:12 ` Jakub Narebski 2009-02-23 9:55 ` Wincent Colaiuta 1 sibling, 0 replies; 40+ messages in thread From: Jakub Narebski @ 2009-02-22 22:12 UTC (permalink / raw) To: Linus Torvalds; +Cc: Felipe Contreras, Junio C Hamano, Git Mailing List 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC/PATCH] revision.c: add --format option for 'git log' 2009-02-22 20:34 ` Linus Torvalds 2009-02-22 22:12 ` Jakub Narebski @ 2009-02-23 9:55 ` Wincent Colaiuta 1 sibling, 0 replies; 40+ messages in thread From: Wincent Colaiuta @ 2009-02-23 9:55 UTC (permalink / raw) To: Linus Torvalds; +Cc: Felipe Contreras, Junio C Hamano, Git Mailing List 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
end of thread, other threads:[~2009-02-27 18:55 UTC | newest] Thread overview: 40+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-02-21 15:26 [RFC/PATCH] revision.c: add --format option for 'git log' Felipe Contreras 2009-02-22 16:49 ` Junio C Hamano 2009-02-22 17:18 ` Felipe Contreras 2009-02-22 17:53 ` Junio C Hamano 2009-02-22 18:06 ` Junio C Hamano 2009-02-22 18:14 ` Felipe Contreras 2009-02-22 18:37 ` Junio C Hamano 2009-02-22 18:55 ` Felipe Contreras 2009-02-23 6:39 ` Junio C Hamano 2009-02-24 0:56 ` Felipe Contreras 2009-02-24 1:03 ` Felipe Contreras 2009-02-24 1:33 ` Junio C Hamano 2009-02-24 1:55 ` Nanako Shiraishi 2009-02-24 8:00 ` Junio C Hamano 2009-02-24 9:34 ` Felipe Contreras 2009-02-24 4:06 ` [PATCH] Add --format that is a synonym to --pretty Nanako Shiraishi 2009-02-24 4:50 ` Jeff King 2009-02-24 5:33 ` Junio C Hamano 2009-02-24 5:45 ` Jeff King 2009-02-24 9:59 ` [PATCH 0/3] --format, --pretty and --oneline Nanako Shiraishi 2009-02-24 9:59 ` [PATCH 1/3] Add --format that is a synonym to --pretty Nanako Shiraishi 2009-02-24 9:59 ` [PATCH 2/3] Give short-hands to --pretty=tformat:%formatstring Nanako Shiraishi 2009-02-24 9:59 ` [PATCH 3/3] Add --oneline that is a synonym to "--pretty=oneline --abbrev-commit" Nanako Shiraishi 2009-02-24 17:38 ` Junio C Hamano 2009-02-24 21:06 ` [PATCH] Add tests for git log --pretty, --format and --oneline Felipe Contreras 2009-02-25 9:54 ` Junio C Hamano 2009-02-25 9:57 ` Jeff King 2009-02-25 10:16 ` Junio C Hamano 2009-02-25 10:20 ` Jeff King 2009-02-24 11:02 ` [PATCH] bash completion: add --format= and --oneline options for "git log" Teemu Likonen 2009-02-24 13:33 ` [PATCH v2] " Teemu Likonen 2009-02-24 15:39 ` Shawn O. Pearce 2009-02-24 15:47 ` Teemu Likonen 2009-02-24 15:57 ` Shawn O. Pearce 2009-02-24 16:14 ` Teemu Likonen 2009-02-27 18:53 ` Teemu Likonen 2009-02-24 8:35 ` [RFC/PATCH] revision.c: add --format option for 'git log' Felipe Contreras 2009-02-22 20:34 ` Linus Torvalds 2009-02-22 22:12 ` Jakub Narebski 2009-02-23 9:55 ` Wincent Colaiuta
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.