{"thread":{"id":"27492","subject":"git show and the --quiet option","startedAt":"2011-05-28T16:53:28Z","lastAt":"2011-06-05T23:13:30Z","messageCount":10,"participants":["Gustaf Hendeby","Carlos Martín Nieto","Junio C Hamano","Drew Northup"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"168916","messageId":"4DE12888.1040506@isy.liu.se","threadId":"27492","inReplyTo":null,"subject":"git show and the --quiet option","fromName":"Gustaf Hendeby","fromEmail":"hendeby@isy.liu.se","sentAt":"2011-05-28T16:53:28Z","receivedAt":"2011-05-28T16:53:28Z","isPatch":false,"sender":{"key":"hendeby@isy.liu.se","avatar":"https://avatars.githubusercontent.com/u/730316?v=4"},"body":"Hello everyone,\n\nI was playing around with \"git show\" lately and realized it has changed\nits behavior regarding the --quiet option, which no longer suppresses\nthe diff output as it used to. The behavior change happened in\n1c40c36b (\"log: convert to parse-options\"). Was this intentional?\n\nThe commit message talks about the --quiet handling being improved and\nthe \"git show\" help doesn't mention a --quiet option. Is the simple\nanswer that the previous behavior was incorrect?\n\n/Gustaf\n"},{"id":"168917","messageId":"20110528172611.GB28708@centaur.lab.cmartin.tk","threadId":"27492","inReplyTo":"4DE12888.1040506@isy.liu.se","subject":"Re: git show and the --quiet option","fromName":"Carlos Martín Nieto","fromEmail":"cmn@elego.de","sentAt":"2011-05-28T17:26:11Z","receivedAt":"2011-05-28T17:26:11Z","isPatch":false,"sender":{"key":"cmn@elego.de","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"On Sat, May 28, 2011 at 06:53:28PM +0200, Gustaf Hendeby wrote:\n> Hello everyone,\n> \n> I was playing around with \"git show\" lately and realized it has changed\n> its behavior regarding the --quiet option, which no longer suppresses\n> the diff output as it used to. The behavior change happened in\n> 1c40c36b (\"log: convert to parse-options\"). Was this intentional?\n\nVery much so.\n\n> \n> The commit message talks about the --quiet handling being improved and\n> the \"git show\" help doesn't mention a --quiet option. Is the simple\n> answer that the previous behavior was incorrect?\n\nYes.\n\n The long answer is that the log family (and git-format-patch, which\nis where this started) never actually accepted --quiet, so it would\nget passed down to the diff machinery. This (for complicated reasons\nI'm not sure I comletely understand, but that have to do with the\ninternal handling of 'quiet' as 'quick') caused every second commit\nnot to show.\n\n As you noticed, the man page never mentions a --quiet option\n(because, honestly, it doesn't make any sense), so any use of that\nflag is wrong. Part of what the patch does is make --quiet a no-op to\nguard against the effect of disappearing commits.\n\n How are you using the --quiet option and why would you even need it?\n\nCheers,\n cmn\n-- \nCarlos Martín Nieto | http://cmartin.tk\n\n\"¿Cómo voy a decir bobadas si soy mudo?\" -- CACHAI\n"},{"id":"168918","messageId":"7vy61qpv59.fsf@alter.siamese.dyndns.org","threadId":"27492","inReplyTo":"4DE12888.1040506@isy.liu.se","subject":"Re: git show and the --quiet option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-05-28T17:55:30Z","receivedAt":"2011-05-28T17:55:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Gustaf Hendeby writes:\n\n> I was playing around with \"git show\" lately and realized it has changed\n> its behavior regarding the --quiet option, which no longer suppresses\n> the diff output as it used to.\n\nThe official and right way to suppress diff output from \"show\" has always\nbeen with the \"-s\" option, and it should still work. Otherwise please\nreport a bug here.\n\nThanks.\n"},{"id":"168919","messageId":"4DE13906.9030806@isy.liu.se","threadId":"27492","inReplyTo":"20110528172611.GB28708@centaur.lab.cmartin.tk","subject":"Re: git show and the --quiet option","fromName":"Gustaf Hendeby","fromEmail":"hendeby@isy.liu.se","sentAt":"2011-05-28T18:03:50Z","receivedAt":"2011-05-28T18:03:50Z","isPatch":false,"sender":{"key":"hendeby@isy.liu.se","avatar":"https://avatars.githubusercontent.com/u/730316?v=4"},"body":"Hi Carlos,\n\nthanks for the detailed answer.\n\nOn 05/28/2011 07:26 PM, Carlos Martín Nieto wrote:\n> On Sat, May 28, 2011 at 06:53:28PM +0200, Gustaf Hendeby wrote:\n>> Hello everyone,\n>>\n>> I was playing around with \"git show\" lately and realized it has changed\n>> its behavior regarding the --quiet option, which no longer suppresses\n>> the diff output as it used to. The behavior change happened in\n>> 1c40c36b (\"log: convert to parse-options\"). Was this intentional?\n> How are you using the --quiet option and why would you even need it?\n\nI used\n\ngit show --quiet --pretty=\"format:%ci\" HEAD\n\nto extract the commit date of HEAD, and I simply replaced it with\n\ngit log -1 --quiet --pretty=\"format:%ci\" HEAD\n\nThough, the email from Junio suggests I should use (and this works)\n\ngit show -a --pretty=\"format:%ci\" HEAD\n\nstill, I wonder if there is no better/more efficient solution to this.\n\n/Gustaf\n"},{"id":"168921","messageId":"7vtycepto2.fsf@alter.siamese.dyndns.org","threadId":"27492","inReplyTo":"7vy61qpv59.fsf@alter.siamese.dyndns.org","subject":"Re: git show and the --quiet option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-05-28T18:27:25Z","receivedAt":"2011-05-28T18:27:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n>> I was playing around with \"git show\" lately and realized it has changed\n>> its behavior regarding the --quiet option, which no longer suppresses\n>> the diff output as it used to.\n>\n> The official and right way to suppress diff output from \"show\" has always\n> been with the \"-s\" option, and it should still work. Otherwise please\n> report a bug here.\n\nHaving said that, I think this is a minor regression.\n\n\"git show A B C\" has been about showing objects (not commits) A and B and\nC. It picks a convenient format for human consumption for each type, and\nshows commit as if it were given to \"log -1 -p\", tree as if it were given\nto \"ls-tree --name-only\", blob as if it were given to \"cat-file blob\".\n\nBut recently, Linus bolted \"git show A..B\" on to it, and in a way that is\nquite wrong. It walks the history by accident, not by design. This makes\nfixing this regression somewhat complex, I suspect.\n\nGiven the existing machinery to \"show\" each individual object given from\nthe command line, one would naturally imagine that we have a routine that\ntakes one object, tells its object type, and formats the object in the\nrepresentation suitable for human consumption, and have a loop over the\ncommand line to call that routine with each object from the command line.\nAnd \"git show A..B\" would first walk to find individual commit objects\nbetween A and B, and feed the same routine with these commits one by one.\n\nNot so. The current implementation walks the history between A..B as a\nside effect of showing a commit (starting from B) and works by pure\naccident.\n\nCase in point: \"git show master master\" shows two copies of the same\ncommit, as it should. \"git show master^..master master\" does not. The\nreason? Walking between \"master^..master\" is done as a side effect of\nshowing \"master^..master\" and marks commit object \"master\" already shown,\nand makes the command ignore the second argument.\n\nA worse example can be seen by running something silly like \"git show\nmaster~10 master^..master\", which you would expect to see two commits\n(master~10 and master). Do not do this on anything with a deep history\nlike the kernel repository---it will walk down to the root commit.\n\nI think the ideal fix would be to fix the \"show A..B\" support (one\npossible solution would be to simply disable it, but I'd see it as the\nlast resort) so that it first collects the commit objects in a queue by\nproperly walking (and clean the object flags that were used to control the\nwalking after we know what commits are in the range), expand A..B into\nthese commits on the command line arguments list, and then run the\nresulting command line arguments through the traditional \"git show\"\nmachinery that shows one object at a time.\n\nIf we go that route, then we should always use \"quiet\" during the internal\nhistory walking that expands A..B to the set of commits in the range with\nor without command line --quiet. And then make both --quiet and -s from\nthe command line to control if the patch is shown when showing a commit.\n"},{"id":"168923","messageId":"7vhb8eprcb.fsf@alter.siamese.dyndns.org","threadId":"27492","inReplyTo":"20110528172611.GB28708@centaur.lab.cmartin.tk","subject":"Re: git show and the --quiet option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-05-28T19:17:40Z","receivedAt":"2011-05-28T19:17:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carlos Martín Nieto writes:\n\n>> 1c40c36b (\"log: convert to parse-options\"). Was this intentional?\n>\n> Very much so.\n>> ...\n> The long answer is that the log family (and git-format-patch, which\n> is where this started) never actually accepted --quiet, so it would\n> get passed down to the diff machinery. This (for complicated reasons\n> I'm not sure I comletely understand, but that have to do with the\n> internal handling of 'quiet' as 'quick') caused every second commit\n> not to show.\n\nYes, \"git format-patch\" that gives empty patch for every other commit\nwould have been incorrect, but \"--quiet\" to squelch patch output,\nespecially in the context of \"show\" whose default is to show patch, is\nsomething people would naturally expect, even though admittedly it was\ndoing so by accident.\n\nHow does this patch look?\n\nIt does not fix \"git show master~10 master^..master\", but instead of just\nhijacking and ignoring the --quiet option like your patch did, it actually\nflips the option the user wanted to affect from the command line.\n\n builtin/log.c | 2 ++\n 1 files changed, 2 insertions(+), 0 deletions(-)\n\ndiff --git a/builtin/log.c b/builtin/log.c\nindex 27849dc..224b167 100644\n--- a/builtin/log.c\n+++ b/builtin/log.c\n@@ -107,6 +107,8 @@ static void cmd_log_init_finish(int argc, const char **argv, const char *prefix,\n \t\t\t PARSE_OPT_KEEP_DASHDASH);\n \n \targc = setup_revisions(argc, argv, rev, opt);\n+\tif (quiet)\n+\t\trev->diffopt.output_format |= DIFF_FORMAT_NO_OUTPUT;\n \n \t/* Any arguments at this point are not recognized */\n \tif (argc > 1)\n"},{"id":"168941","messageId":"20110529132410.GC28708@centaur.lab.cmartin.tk","threadId":"27492","inReplyTo":"4DE13906.9030806@isy.liu.se","subject":"Re: git show and the --quiet option","fromName":"Carlos Martín Nieto","fromEmail":"cmn@elego.de","sentAt":"2011-05-29T13:24:10Z","receivedAt":"2011-05-29T13:24:10Z","isPatch":false,"sender":{"key":"cmn@elego.de","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"On Sat, May 28, 2011 at 08:03:50PM +0200, Gustaf Hendeby wrote:\n> Hi Carlos,\n> \n> thanks for the detailed answer.\n> \n> On 05/28/2011 07:26 PM, Carlos Martín Nieto wrote:\n> > On Sat, May 28, 2011 at 06:53:28PM +0200, Gustaf Hendeby wrote:\n> >> Hello everyone,\n> >>\n> >> I was playing around with \"git show\" lately and realized it has changed\n> >> its behavior regarding the --quiet option, which no longer suppresses\n> >> the diff output as it used to. The behavior change happened in\n> >> 1c40c36b (\"log: convert to parse-options\"). Was this intentional?\n> > How are you using the --quiet option and why would you even need it?\n> \n> I used\n> \n> git show --quiet --pretty=\"format:%ci\" HEAD\n> \n> to extract the commit date of HEAD, and I simply replaced it with\n> \n> git log -1 --quiet --pretty=\"format:%ci\" HEAD\n> \n> Though, the email from Junio suggests I should use (and this works)\n> \n> git show -a --pretty=\"format:%ci\" HEAD\n> \n\nI'm assuming you meant -s instead of -a\n\n> still, I wonder if there is no better/more efficient solution to this.\n> \n\nThere is --format, so that line would look like\n\n git show -s --format=\"%ci\" HEAD\n\nwhich IMO is quite compact and self-explanatory. Depending on how much\ncontrol you have over the environment, you could set up an alias like\n\n git config alias.show-commit 'show -s'\n\nor even\n\n git config alias.show-commit-date 'show -s --format=\"%ci\"'\n\n cmn\n-- \nCarlos Martín Nieto | http://cmartin.tk\n\n\"¿Cómo voy a decir bobadas si soy mudo?\" -- CACHAI\n"},{"id":"168983","messageId":"20110530093259.GA2990@bee.lab.cmartin.tk","threadId":"27492","inReplyTo":"7vhb8eprcb.fsf@alter.siamese.dyndns.org","subject":"Re: git show and the --quiet option","fromName":"Carlos Martín Nieto","fromEmail":"cmn@elego.de","sentAt":"2011-05-30T09:32:59Z","receivedAt":"2011-05-30T09:32:59Z","isPatch":false,"sender":{"key":"cmn@elego.de","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"On Sat, May 28, 2011 at 12:17:40PM -0700, Junio C Hamano wrote:\n> Carlos Martín Nieto writes:\n> \n> >> 1c40c36b (\"log: convert to parse-options\"). Was this intentional?\n> >\n> > Very much so.\n> >> ...\n> > The long answer is that the log family (and git-format-patch, which\n> > is where this started) never actually accepted --quiet, so it would\n> > get passed down to the diff machinery. This (for complicated reasons\n> > I'm not sure I comletely understand, but that have to do with the\n> > internal handling of 'quiet' as 'quick') caused every second commit\n> > not to show.\n> \n> Yes, \"git format-patch\" that gives empty patch for every other commit\n> would have been incorrect, but \"--quiet\" to squelch patch output,\n> especially in the context of \"show\" whose default is to show patch, is\n> something people would naturally expect, even though admittedly it was\n> doing so by accident.\n> \n> How does this patch look?\n> \n> It does not fix \"git show master~10 master^..master\", but instead of just\n> hijacking and ignoring the --quiet option like your patch did, it actually\n> flips the option the user wanted to affect from the command line.\n\nIt's fine if that's what we want to do. The reason I blocked --quiet\ninstead of converting it to -s is because it seemed less surprising\nthan passing --quiet and still getting output (if I pass --quiet, I'd\nexpect the application to really be quiet), which doesn't happen in\nthe commands that accept --quiet on purpose. Then again, the log\nfamily doesn't make any sense without any output, so if you argue that\nway, --quiet means \"quieter\", which makes the interface less\nconsistent, but I don't feel that strongly about it\n\nSo sure, if you think it helps, apply it. \n\n> \n> builtin/log.c | 2 ++\n> 1 files changed, 2 insertions(+), 0 deletions(-)\n> \n> diff --git a/builtin/log.c b/builtin/log.c\n> index 27849dc..224b167 100644\n> --- a/builtin/log.c\n> +++ b/builtin/log.c\n> @@ -107,6 +107,8 @@ static void cmd_log_init_finish(int argc, const char **argv, const char *prefix,\n> \t\t\t PARSE_OPT_KEEP_DASHDASH);\n> \n> \targc = setup_revisions(argc, argv, rev, opt);\n> +\tif (quiet)\n> +\t\trev->diffopt.output_format |= DIFF_FORMAT_NO_OUTPUT;\n> \n> \t/* Any arguments at this point are not recognized */\n> \tif (argc > 1)\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n> \n"},{"id":"169212","messageId":"1307039169.28941.35.camel@drew-northup.unet.maine.edu","threadId":"27492","inReplyTo":"20110530093259.GA2990@bee.lab.cmartin.tk","subject":"Re: git show and the --quiet option","fromName":"Drew Northup","fromEmail":"drew.northup@maine.edu","sentAt":"2011-06-02T18:26:09Z","receivedAt":"2011-06-02T18:26:09Z","isPatch":false,"sender":{"key":"drew.northup@maine.edu","avatar":"https://avatars.githubusercontent.com/u/18331571?v=4"},"body":"\nOn Mon, 2011-05-30 at 11:32 +0200, Carlos Martín Nieto wrote:\n> On Sat, May 28, 2011 at 12:17:40PM -0700, Junio C Hamano wrote:\n> > Carlos Martín Nieto writes:\n> > \n\n> > How does this patch look?\n> > \n> > It does not fix \"git show master~10 master^..master\", but instead of just\n> > hijacking and ignoring the --quiet option like your patch did, it actually\n> > flips the option the user wanted to affect from the command line.\n> \n> It's fine if that's what we want to do. The reason I blocked --quiet\n> instead of converting it to -s is because it seemed less surprising\n> than passing --quiet and still getting output (if I pass --quiet, I'd\n> expect the application to really be quiet), which doesn't happen in\n> the commands that accept --quiet on purpose. Then again, the log\n> family doesn't make any sense without any output, so if you argue that\n> way, --quiet means \"quieter\", which makes the interface less\n> consistent, but I don't feel that strongly about it\n\nThere's a lot of stuff out there for which --quiet does not imply\n--silent. I side with Junio on the solution.\n\n-- \n-Drew Northup\n________________________________________________\n\"As opposed to vegetable or mineral error?\"\n-John Pescatore, SANS NewsBites Vol. 12 Num. 59\n"},{"id":"169328","messageId":"20110605231330.GB30081@centaur.lab.cmartin.tk","threadId":"27492","inReplyTo":"1307039169.28941.35.camel@drew-northup.unet.maine.edu","subject":"Re: git show and the --quiet option","fromName":"Carlos Martín Nieto","fromEmail":"carlos@cmartin.tk","sentAt":"2011-06-05T23:13:30Z","receivedAt":"2011-06-05T23:13:30Z","isPatch":false,"sender":{"key":"carlos@cmartin.tk","avatar":"https://gravatar.com/avatar/956bfe8371004f2960febf266a6af789f60cdc01fbae48bb151ad4c9b532c3a2?d=mp&s=160"},"body":"On Thu, Jun 02, 2011 at 02:26:09PM -0400, Drew Northup wrote:\n> \n> On Mon, 2011-05-30 at 11:32 +0200, Carlos Martín Nieto wrote:\n> > On Sat, May 28, 2011 at 12:17:40PM -0700, Junio C Hamano wrote:\n> > > Carlos Martín Nieto writes:\n> > > \n> \n> > > How does this patch look?\n> > > \n> > > It does not fix \"git show master~10 master^..master\", but instead of just\n> > > hijacking and ignoring the --quiet option like your patch did, it actually\n> > > flips the option the user wanted to affect from the command line.\n> > \n> > It's fine if that's what we want to do. The reason I blocked --quiet\n> > instead of converting it to -s is because it seemed less surprising\n> > than passing --quiet and still getting output (if I pass --quiet, I'd\n> > expect the application to really be quiet), which doesn't happen in\n> > the commands that accept --quiet on purpose. Then again, the log\n> > family doesn't make any sense without any output, so if you argue that\n> > way, --quiet means \"quieter\", which makes the interface less\n> > consistent, but I don't feel that strongly about it\n> \n> There's a lot of stuff out there for which --quiet does not imply\n> --silent. I side with Junio on the solution.\n\nThen don't let me stop you.\n\n cmn\n-- \nCarlos Martín Nieto | http://cmartin.tk\n\n\"¿Cómo voy a decir bobadas si soy mudo?\" -- CACHAI\n"}]}