{"thread":{"id":"7510","subject":"[PATCH] Show binary file size change in diff --stat","startedAt":"2007-04-04T13:14:14Z","lastAt":"2007-04-04T17:47:56Z","messageCount":12,"participants":["Andy Parkins","Rogan Dawes","Geert Bosch","Johannes Schindelin","Linus Torvalds","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"38613","messageId":"200704041414.14797.andyparkins@gmail.com","threadId":"7510","inReplyTo":null,"subject":"[PATCH] Show binary file size change in diff --stat","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-04-04T13:14:14Z","receivedAt":"2007-04-04T13:14:14Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"Previously, a binary file in the diffstat would show as:\n\n some-binary-file.bin       |  Bin\n\nThe space after the \"Bin\" was never used.  This patch changes binary\nlines in the diffstat to be:\n\n some-binary-file.bin       |  Bin 12345 -> 123456 bytes\n\nThe very nice \"->\" notation was suggested by Johannes Schindelin, and\nshows the before and after sizes more clearly than \"+\" and \"-\" would.\nIf a size is 0 it's not shown (although it would probably be better to\ntreat no-file differently from zero-byte-file).\n\nThe user can see what changed in the binary file, and how big the new\nfile is.  This is in keeping with the information in the rest of the\ndiffstat.\n\nThe diffstat_t members \"added\" and \"deleted\" were unused when the file\nwas binary, so this patch loads them with the file sizes in\nbuiltin_diffstat().  These figures are then read in show_stats() when\nthe file is marked binary.\n\nSigned-off-by: Andy Parkins <andyparkins@gmail.com>\n---\nThis is a resend; I still wish for it every time I see a --stat with\nbinary files changed.\n\nIs there any objection to it that I can address?\n\n\n diff.c |   13 ++++++++++---\n 1 files changed, 10 insertions(+), 3 deletions(-)\n\ndiff --git a/diff.c b/diff.c\nindex d8f9242..1a527e9 100644\n--- a/diff.c\n+++ b/diff.c\n@@ -811,7 +811,12 @@ static void show_stats(struct diffstat_t* data, struct diff_options *options)\n \n \t\tif (data->files[i]->is_binary) {\n \t\t\tshow_name(prefix, name, len, reset, set);\n-\t\t\tprintf(\"  Bin\\n\");\n+\t\t\tprintf(\"  Bin \");\n+\t\t\tprintf(\"%s%i%s\", del_c, deleted, reset);\n+\t\t\tprintf(\" -> \");\n+\t\t\tprintf(\"%s%i%s\", add_c, added, reset);\n+\t\t\tprintf(\" bytes\");\n+\t\t\tprintf(\"\\n\");\n \t\t\tgoto free_diffstat_file;\n \t\t}\n \t\telse if (data->files[i]->is_unmerged) {\n@@ -1185,9 +1190,11 @@ static void builtin_diffstat(const char *name_a, const char *name_b,\n \tif (fill_mmfile(&mf1, one) < 0 || fill_mmfile(&mf2, two) < 0)\n \t\tdie(\"unable to read files to diff\");\n \n-\tif (mmfile_is_binary(&mf1) || mmfile_is_binary(&mf2))\n+\tif (mmfile_is_binary(&mf1) || mmfile_is_binary(&mf2)) {\n \t\tdata->is_binary = 1;\n-\telse {\n+\t\tdata->added = mf2.size;\n+\t\tdata->deleted = mf1.size;\n+\t} else {\n \t\t/* Crazy xdl interfaces.. */\n \t\txpparam_t xpp;\n \t\txdemitconf_t xecfg;\n-- \n1.5.1.rc3.703.g5709-dirty\n"},{"id":"38617","messageId":"4613A974.60808@dawes.za.net","threadId":"7510","inReplyTo":"200704041414.14797.andyparkins@gmail.com","subject":"Re: [PATCH] Show binary file size change in diff --stat","fromName":"Rogan Dawes","fromEmail":"lists@dawes.za.net","sentAt":"2007-04-04T13:34:44Z","receivedAt":"2007-04-04T13:34:44Z","isPatch":true,"sender":{"key":"lists@dawes.za.net","avatar":null},"body":"Andy Parkins wrote:\n> Previously, a binary file in the diffstat would show as:\n> \n>  some-binary-file.bin       |  Bin\n> \n> The space after the \"Bin\" was never used.  This patch changes binary\n> lines in the diffstat to be:\n> \n>  some-binary-file.bin       |  Bin 12345 -> 123456 bytes\n> \n> The very nice \"->\" notation was suggested by Johannes Schindelin, and\n> shows the before and after sizes more clearly than \"+\" and \"-\" would.\n> If a size is 0 it's not shown (although it would probably be better to\n> treat no-file differently from zero-byte-file).\n> \n> The user can see what changed in the binary file, and how big the new\n> file is.  This is in keeping with the information in the rest of the\n> diffstat.\n> \n> The diffstat_t members \"added\" and \"deleted\" were unused when the file\n> was binary, so this patch loads them with the file sizes in\n> builtin_diffstat().  These figures are then read in show_stats() when\n> the file is marked binary.\n> \n> Signed-off-by: Andy Parkins <andyparkins@gmail.com>\n> ---\n> This is a resend; I still wish for it every time I see a --stat with\n> binary files changed.\n> \n> Is there any objection to it that I can address?\n\n\nWell, how about my comments in <45E67978.9030805@dawes.za.net>, \nsuggesting that the edit difference (number of steps required to \ntransform one to the other) would be a better indication?\n\nI think it is better because it is consistent with what we currently do \nfor text files: show the number of lines added/deleted.\n\nFor binary files, it would be consistent to show the number of bytes \nadded/deleted. I have not investigated the output format for the \nlibxdiff binary patch format, but hopefully it would not be too \ndifficult to calculate the deletions and additions.\n\nRogan\n"},{"id":"38619","messageId":"BAFDAA7B-60EC-44FD-8DAA-EB2F9C835F51@adacore.com","threadId":"7510","inReplyTo":"4613A974.60808@dawes.za.net","subject":"Re: [PATCH] Show binary file size change in diff --stat","fromName":"Geert Bosch","fromEmail":"bosch@adacore.com","sentAt":"2007-04-04T14:40:46Z","receivedAt":"2007-04-04T14:40:46Z","isPatch":true,"sender":{"key":"bosch@adacore.com","avatar":null},"body":"\nOn Apr 4, 2007, at 09:34, Rogan Dawes wrote:\n\n> For binary files, it would be consistent to show the number of  \n> bytes added/deleted. I have not investigated the output format for  \n> the libxdiff binary patch format, but hopefully it would not be too  \n> difficult to calculate the deletions and additions.\n\nFor binary files it is impractical to do insert/delete type of  \ndifferences.\nFor text files, treating lines as indivisible entities to insert/delete\nmake some sense. For binary files, you'd have to use some arbitrary\ncontext-defined breakpoints and then go from there. The result would\nbe some very complicated and unclear algorithm that would have no use\nin the real world.\n\nMany binary files, such as an images, waveforms or virtually any  \ncompressed\nstream, can change in a way that changes all bytes in the file, while\nthe changes in the displayed image or the uncompressed stream are\nimperceptible or absent. Guessing semantic differences between binary\nblobs is hopeless and subjective, while differences in size are fact.\n\n   -Geert\n"},{"id":"38620","messageId":"200704041540.59977.andyparkins@gmail.com","threadId":"7510","inReplyTo":"4613A974.60808@dawes.za.net","subject":"Re: [PATCH] Show binary file size change in diff --stat","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-04-04T14:40:58Z","receivedAt":"2007-04-04T14:40:58Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Wednesday 2007 April 04 14:34, Rogan Dawes wrote:\n\n> Well, how about my comments in <45E67978.9030805@dawes.za.net>,\n> suggesting that the edit difference (number of steps required to\n> transform one to the other) would be a better indication?\n\nPerhaps.  There is certainly a difference between:\n\n somefile.bin  | 1000 -> 1000 bytes\n\nand\n\n somefile.bin  | 500 bytes removed, 500 bytes added\n\n> I think it is better because it is consistent with what we currently do\n> for text files: show the number of lines added/deleted.\n\nThe thing is, \"lines\" is an understandable unit for a text file, so it's \nuseful to show.  I'm not sure the same is true of \"bytes\" for a binary file.  \nThose bytes could represent anything; the true unit of a binary file is \ndependent on its type.\n\n> For binary files, it would be consistent to show the number of bytes\n> added/deleted. I have not investigated the output format for the\n> libxdiff binary patch format, but hopefully it would not be too\n> difficult to calculate the deletions and additions.\n\nI'm inclined to agree with Johannes, while it's certainly something \nthat /could/ be shown - is it more useful?  There is no guarantee that a \nsmall change in the underlying content is represented by a small change in \nthe binary diff.\n\nAs an example: compress a file, change a byte, compress it again, perform a \nbinary diff; what is that diff telling you about the change?  (My answer is: \nnot much).\n\n\nAndy\n\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"38627","messageId":"4613C97C.9050600@dawes.za.net","threadId":"7510","inReplyTo":"200704041540.59977.andyparkins@gmail.com","subject":"Re: [PATCH] Show binary file size change in diff --stat","fromName":"Rogan Dawes","fromEmail":"lists@dawes.za.net","sentAt":"2007-04-04T15:51:24Z","receivedAt":"2007-04-04T15:51:24Z","isPatch":true,"sender":{"key":"lists@dawes.za.net","avatar":null},"body":"Andy Parkins wrote:\n> On Wednesday 2007 April 04 14:34, Rogan Dawes wrote:\n> \n>> Well, how about my comments in <45E67978.9030805@dawes.za.net>,\n>> suggesting that the edit difference (number of steps required to\n>> transform one to the other) would be a better indication?\n> \n> Perhaps.  There is certainly a difference between:\n> \n>  somefile.bin  | 1000 -> 1000 bytes\n> \n> and\n> \n>  somefile.bin  | 500 bytes removed, 500 bytes added\n> \n>> I think it is better because it is consistent with what we currently do\n>> for text files: show the number of lines added/deleted.\n> \n> The thing is, \"lines\" is an understandable unit for a text file, so it's \n> useful to show.  I'm not sure the same is true of \"bytes\" for a binary file.  \n> Those bytes could represent anything; the true unit of a binary file is \n> dependent on its type.\n\nI think bytes are the only reasonable unit for a binary file, since we \nhave no idea what a meaningful divisor may be. So, defaulting to the \nsmallest possible unit (other than going to the bit-level) makes perfect \nsense.\n\n>> For binary files, it would be consistent to show the number of bytes\n>> added/deleted. I have not investigated the output format for the\n>> libxdiff binary patch format, but hopefully it would not be too\n>> difficult to calculate the deletions and additions.\n> \n> I'm inclined to agree with Johannes, while it's certainly something \n> that /could/ be shown - is it more useful?  There is no guarantee that a \n> small change in the underlying content is represented by a small change in \n> the binary diff.\n> \n> As an example: compress a file, change a byte, compress it again, perform a \n> binary diff; what is that diff telling you about the change?  (My answer is: \n> not much).\n\nWell, at least as much as the resulting sizes tell you, if not more.\n\nHere is a counter example for a text file, where lines changed do not \nactually reflect the real changes in the file: the contents of an XML \nfile being wrapped in an additional tag.\n\nSemantically, all that has changed is an opening and closing tag. But, \nwe still show that on a line by line basis, the entire file has changed \n(because the indentation changes). So you'd have n lines deleted, and \nn+2 lines added (for the additional opening and closing tag).\n\n> Andy\n\nI still maintain that showing bytes changed is the only consistent thing \nto do, unless we have additional logic that allows us to do \"per \nfile-type\" diff statistics. Maybe .gitattributes will allow/enable this?\n\nRegards,\n\nRogan\n\nP.S. I'm not volunteering to inflict my novice C-skills on the git \ncommunity, so this is really \"just my 2c\"\n"},{"id":"38628","messageId":"4613CB87.2090306@dawes.za.net","threadId":"7510","inReplyTo":"BAFDAA7B-60EC-44FD-8DAA-EB2F9C835F51@adacore.com","subject":"Re: [PATCH] Show binary file size change in diff --stat","fromName":"Rogan Dawes","fromEmail":"lists@dawes.za.net","sentAt":"2007-04-04T16:00:07Z","receivedAt":"2007-04-04T16:00:07Z","isPatch":true,"sender":{"key":"lists@dawes.za.net","avatar":null},"body":"Geert Bosch wrote:\n> \n> On Apr 4, 2007, at 09:34, Rogan Dawes wrote:\n> \n>> For binary files, it would be consistent to show the number of bytes \n>> added/deleted. I have not investigated the output format for the \n>> libxdiff binary patch format, but hopefully it would not be too \n>> difficult to calculate the deletions and additions.\n> \n> For binary files it is impractical to do insert/delete type of differences.\n> For text files, treating lines as indivisible entities to insert/delete\n> make some sense. For binary files, you'd have to use some arbitrary\n> context-defined breakpoints and then go from there. The result would\n> be some very complicated and unclear algorithm that would have no use\n> in the real world.\n> \n> Many binary files, such as an images, waveforms or virtually any compressed\n> stream, can change in a way that changes all bytes in the file, while\n> the changes in the displayed image or the uncompressed stream are\n> imperceptible or absent. Guessing semantic differences between binary\n> blobs is hopeless and subjective, while differences in size are fact.\n> \n>   -Geert\n\nAs per my mail to Andy, we *already* do this for text files. e.g. wrap \nan XML document in an additional tag, and update the indentation to match.\n\nThe semantic change is minimal (perhaps 2 new lines), but the reported \nchange reflects n lines deleted, and n+2 added.\n\nExactly because we *don't* do any semantic analysis (for text or binary \nfiles), we should simply report the number of bytes changed, exactly as \nwe do for text files (reporting number of lines changed). This is \n_consistent_ with what we do currently for text files.\n\nNote that Andy's apparent preference (to know how the sizes have \nchanged) can still largely be satisfied by this approach.\n\n  somefile.bin  | 1000 -> 1000 bytes\n\nand\n\n  somefile.bin  | 500 bytes removed, 500 bytes added\n\nYou can still see that the overall size of the file has not changed, but \nyou get the additional information about how many bytes were actually \nchanged at the same time, which you don't get just showing the sizes.\n\nRogan\n"},{"id":"38630","messageId":"Pine.LNX.4.63.0704041819340.4045@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"7510","inReplyTo":"4613C97C.9050600@dawes.za.net","subject":"Re: [PATCH] Show binary file size change in diff --stat","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-04-04T16:22:13Z","receivedAt":"2007-04-04T16:22:13Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 4 Apr 2007, Rogan Dawes wrote:\n\n> Andy Parkins wrote:\n>\n> > As an example: compress a file, change a byte, compress it again, \n> > perform a binary diff; what is that diff telling you about the change?  \n> > (My answer is: not much).\n> \n> Well, at least as much as the resulting sizes tell you, if not more.\n\nThe subtle difference: your approach is _expensive_ in terms of CPU time, \nwhile the byte change approach is _dirt cheap_.\n\nSince it seems that there are gazillions of examples where one or the \nother (or both) do not make sense, I'd rather have the fast one.\n\nHOWEVER, there is something I really would like to have, namely a clear \ndistinction between new file / deleted file, and 0->n / n->0 changes.\n\nCiao,\nDscho\n"},{"id":"38631","messageId":"4613D1C1.6010002@dawes.za.net","threadId":"7510","inReplyTo":"Pine.LNX.4.63.0704041819340.4045@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Show binary file size change in diff --stat","fromName":"Rogan Dawes","fromEmail":"lists@dawes.za.net","sentAt":"2007-04-04T16:26:41Z","receivedAt":"2007-04-04T16:26:41Z","isPatch":true,"sender":{"key":"lists@dawes.za.net","avatar":null},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Wed, 4 Apr 2007, Rogan Dawes wrote:\n> \n>> Andy Parkins wrote:\n>>\n>>> As an example: compress a file, change a byte, compress it again, \n>>> perform a binary diff; what is that diff telling you about the change?  \n>>> (My answer is: not much).\n>> Well, at least as much as the resulting sizes tell you, if not more.\n> \n> The subtle difference: your approach is _expensive_ in terms of CPU time, \n> while the byte change approach is _dirt cheap_.\n\nI don't dispute that for a second.\n\n> Since it seems that there are gazillions of examples where one or the \n> other (or both) do not make sense, I'd rather have the fast one.\n\nFair enough.\n\nRogan\n"},{"id":"38633","messageId":"Pine.LNX.4.64.0704040935350.6730@woody.linux-foundation.org","threadId":"7510","inReplyTo":"Pine.LNX.4.63.0704041819340.4045@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Show binary file size change in diff --stat","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-04-04T16:40:13Z","receivedAt":"2007-04-04T16:40:13Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 4 Apr 2007, Johannes Schindelin wrote:\n> \n> The subtle difference: your approach is _expensive_ in terms of CPU time, \n> while the byte change approach is _dirt cheap_.\n\nWell, you could do a combination (still dirt cheap):\n - show the size before/after (and yes, new/delete should be separate from \n   \"zero size before/after\")\n - show the size of the binary patch.\n\nNo \"X added bytes\" vs \"Y bytes deleted\", just \"size of binary patch\". It \ncould be really small, even if 10k was deleted, or the file was totally \nre-organized by moving chunks around.\n\nIt would still be a meaningful thing to know - if only because it tells \nyou how much space the delta takes. So even if it's a .jpg, and the actual \n*picture* didn't change a lot (ie you did some new version with color \ncorrection or something: it looks similar to the old one, but the *diff* \nis basically \"rewrite it all\"), knowing the size of the delta at least has \nthe meaning of \"this is how basically much space it will take when you \nsend the binary diff in an email\".\n\nThat's fairly close to what \"5 new lines, 1 deleted line\" message means. \nIt's another way to give you an approximate idea of how big the changes \nwere.\n\n\t\tLinus\n"},{"id":"38635","messageId":"Pine.LNX.4.63.0704041856210.4045@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"7510","inReplyTo":"Pine.LNX.4.64.0704040935350.6730@woody.linux-foundation.org","subject":"Re: [PATCH] Show binary file size change in diff --stat","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-04-04T16:59:35Z","receivedAt":"2007-04-04T16:59:35Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 4 Apr 2007, Linus Torvalds wrote:\n\n> On Wed, 4 Apr 2007, Johannes Schindelin wrote:\n> > \n> > The subtle difference: your approach is _expensive_ in terms of CPU time, \n> > while the byte change approach is _dirt cheap_.\n> \n> Well, you could do a combination (still dirt cheap):\n>  - show the size before/after (and yes, new/delete should be separate from \n>    \"zero size before/after\")\n>  - show the size of the binary patch.\n\n... and by this (size of binary patch) you mean the deltified object?\n\nIn general, we do not have the binary patch. And the generation of that \nbinary patch is what I was referring to being expensive.\n\nRemember, most binary files are way larger than the average source code \nfiles we have, since it is much, much easier to generate binary data than \nto write meaningful code. Therefore, the binary patch generation has to \nlook at much larger pieces to begin with, which translates into CPU time.\n\nHaving said that, I have to admit that I don't have numbers backing this \nreasoning up. So, if somebody comes up with numbers contradicting my \ntheory, I will gladly change my mind.\n\nCiao,\nDscho\n"},{"id":"38637","messageId":"Pine.LNX.4.64.0704041011170.6730@woody.linux-foundation.org","threadId":"7510","inReplyTo":"Pine.LNX.4.63.0704041856210.4045@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Show binary file size change in diff --stat","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-04-04T17:12:38Z","receivedAt":"2007-04-04T17:12:38Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 4 Apr 2007, Johannes Schindelin wrote:\n> \n> ... and by this (size of binary patch) you mean the deltified object?\n\nyes. Just the size of the delta. Although I guess you're right - we \nmay not have generated that.\n\n\t\tLinus\n"},{"id":"38639","messageId":"7vbqi458vn.fsf@assigned-by-dhcp.cox.net","threadId":"7510","inReplyTo":"Pine.LNX.4.64.0704040935350.6730@woody.linux-foundation.org","subject":"Re: [PATCH] Show binary file size change in diff --stat","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-04T17:47:56Z","receivedAt":"2007-04-04T17:47:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@linux-foundation.org> writes:\n\n> On Wed, 4 Apr 2007, Johannes Schindelin wrote:\n>> \n>> The subtle difference: your approach is _expensive_ in terms of CPU time, \n>> while the byte change approach is _dirt cheap_.\n>\n> Well, you could do a combination (still dirt cheap):\n>  - show the size before/after (and yes, new/delete should be separate from \n>    \"zero size before/after\")\n>  - show the size of the binary patch.\n>\n> No \"X added bytes\" vs \"Y bytes deleted\", just \"size of binary patch\". It \n> could be really small, even if 10k was deleted, or the file was totally \n> re-organized by moving chunks around.\n>\n> It would still be a meaningful thing to know - if only because it tells \n> you how much space the delta takes.\n\nI agree wrt the kind of information to give, except that I am\nnot so sure about new/delete vs zero before/after.  We do not do\nthat for a text file, and when people do care about the\ndistinction, they would use --summary.\n\nI often have wished that we could make --stat imply --summary;\nthe only reason we did not do that is because the --stat option\nstarted its life as an imitation of \"diffstat\".\n\nI've seen our diff-delta change its output size once.  It was a\nnice improvement to make the delta much smaller than before, but\nI had to rewrite the rename similarity in diffcore not to depend\non the diff-delta algorithm change, to keep it stable across\ndiff-delta improvements (the alternative was to futz with the\ndefault threshold).  I suspect we might see similar confusion if\nwe show the delta size, depending on people's expectations.\nThis is a very minor issue, but I thought I should mention it.\n\nThere is a machine readable output format for the same --stat\ninformation called --numstat.  It currently signals the\nbinary-ness by showing '-' instead of line count.  We could\nextend it by showing '-' + number of bytes.\n\nSo here are some more suggestions:\n\n (1) --stat for binary files to show preimage and postimage\n     sizes like this (if we were to do delta size -- otherwise\n     drop \" (.*\" at the end):\n\n\tpenguin.jpg |  Bin 745245 -> 660689 (delta: 4434)\n\n (2) --numstat for binary files to show preimage and postimage\n     sizes like this:\n\n\tpenguin.jpg\t-745245\t-660689\n\n (3) independent from all of the above, make --stat imply\n     --summary and perhaps introduce --no-summary if people do not\n     want --summary given when they say --stat;\n"}]}