{"thread":{"id":"9036","subject":"[PATCH] Add --show-size to git log to print message size","startedAt":"2007-07-14T16:52:10Z","lastAt":"2007-07-25T09:38:01Z","messageCount":29,"participants":["Marco Costalba","Junio C Hamano","Alex Riesen","Sean","Linus Torvalds","Andy Parkins"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"47359","messageId":"e5bfff550707140952hb60735bi95a4f03636c4aa99@mail.gmail.com","threadId":"9036","inReplyTo":null,"subject":"[PATCH] Add --show-size to git log to print message size","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-07-14T16:52:10Z","receivedAt":"2007-07-14T16:52:10Z","isPatch":true,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"Print message size just before the corresponding message\nto speedup the parsing by scripts/porcelains tools.\n\nBecause git log output is normally read incrementally by\nporcelain tools, if message size is ignored then an\nexpensive seek of the delimiting char, as example '\\0'\nmust be done when parsing the output stream.\n\nWith this patch it is possible to avoid an otherwise\nmandatory seek for '\\0' starting from the beginning\nof log body.\n\nSigned-off-by: Marco Costalba \n---\n\nThis little patch makes great difference in loading\nperformance of our loved ;-) tool....and probably\nalso others.\n\nPlease apply.\n\nThanks\nMarco\n\n\n log-tree.c | 3 +++\n revision.c | 4 ++++\n revision.h | 1 +\n 3 files changed, 8 insertions(+), 0 deletions(-)\n\ndiff --git a/log-tree.c b/log-tree.c\nindex 8624d5a..2fb7761 100644\n--- a/log-tree.c\n+++ b/log-tree.c\n@@ -295,6 +295,9 @@ void show_log(struct rev_info *opt,\n \tif (opt->add_signoff)\n \t\tlen = append_signoff(&msgbuf, &msgbuf_len, len,\n \t\t\t\t opt->add_signoff);\n+ \tif (opt->show_size)\n+\t\tprintf(\"size %i\\n\", len);\n+\n \tprintf(\"%s%s%s\", msgbuf, extra, sep);\n \tfree(msgbuf);\n }\ndiff --git a/revision.c b/revision.c\nindex 33ee9ee..3850a1e 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -1136,6 +1136,10 @@ int setup_revisions(int argc,\n \t\t\t\tcontinue;\n \t\t\t}\n+\t\t\tif (!strcmp(arg, \"--show-size\")) {\n+\t\t\t\trevs->show_size = 1;\n+\t\t\t\tcontinue;\n+\t\t\t}\n\n \t\t\t/*\n \t\t\t * Grepping the commit log\ndiff --git a/revision.h b/revision.h\nindex f46b4d5..584b3f1 100644\n--- a/revision.h\n+++ b/revision.h\n@@ -81,6 +81,7 @@ struct rev_info {\n \tconst char\t*log_reencode;\n \tconst char\t*subject_prefix;\n \tint\t\tno_inline;\n+\tint\t\tshow_size;\n\n \t/* Filter by commit log message */\n \tstruct grep_opt\t*grep_filter;\n-- \n1.5.3.rc0.81.g1ed84-dirty\n"},{"id":"47369","messageId":"7vodiehko7.fsf@assigned-by-dhcp.cox.net","threadId":"9036","inReplyTo":"e5bfff550707140952hb60735bi95a4f03636c4aa99@mail.gmail.com","subject":"Re: [PATCH] Add --show-size to git log to print message size","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-14T19:03:52Z","receivedAt":"2007-07-14T19:03:52Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Marco Costalba\" writes:\n\n> Print message size just before the corresponding message\n> to speedup the parsing by scripts/porcelains tools.\n\n> diff --git a/log-tree.c b/log-tree.c\n> index 8624d5a..2fb7761 100644\n> --- a/log-tree.c\n> +++ b/log-tree.c\n> @@ -295,6 +295,9 @@ void show_log(struct rev_info *opt,\n> \tif (opt->add_signoff)\n> \t\tlen = append_signoff(&msgbuf, &msgbuf_len, len,\n> \t\t\t\t opt->add_signoff);\n> + \tif (opt->show_size)\n> +\t\tprintf(\"size %i\\n\", len);\n> +\n> \tprintf(\"%s%s%s\", msgbuf, extra, sep);\n> \tfree(msgbuf);\n> }\n\n\"size\" is a bit vague here. What if we later want to extend\nthings so that you can ask for the entire log entry size\nincluding the patch output part (I am not saying that would be\nan easy change --- I am more worried about the stability of the\nexternal interface). So is --show-\"size\". \"message-size\" would\nhave been a bit easier to swallow, but I sense the problem runs\ndeeper.\n\nThe current code spits out a log message after formatting it in\nits entirety in core, so we happen to have its size upfront.\nHaving to say the size upfront means we close the door for\nalternative implementations that stream the log formatting\nprocessing.\n\nThis is not a problem for log messages per-se, as we\ntraditionally even did not show a commit log over 16kB (these\ndays we are supposed to be unbounded, although I do not know if\nanybody actually tested that). But if we ever want to extend\nthis concept to cover the patch part, so that the reader can\nsplit the \"git log\" output stream into individual commits with\nthe same \"efficiency improvements\" you are seeing from this\npatch, that becomes a real problem, I would think.\n\nNaturally, this reminds me of having to say Content-Length\nupfront vs chunked transfer. Essentially you are treating the\noutput stream from \"git log\" into the pipe as a sequence of\nmessages (and without \"-p\", your \"size\" is exactly what a\n\"Content-Length\" header is). The fact that this analogy works\nonly when the command is run without \"-p\" (but \"--show-size\"\ndoes not check that) bothers me. What would we do when we want\nto help the readers that reads from \"-p\" output?\n\nI have a more basic question. If you are reading from non \"-p\"\noutput, where do you exactly have the wasted cycles in your\nreader's processing? One immediately obvious thing is that you\nwould not have to repeatedly realloc your buffer to keep one\nmessage worth of data in core, but somehow I cannot imagine that\nthat is the source of a huge performance boost.\n\nOne use case that this would give a huge improvement I can think\nof is if you read the stream, and show only every tenth commit.\nYou can discard other 9 out of 10 without even looking at their\ncontents, and being able to read known amount of bytes and\nimmediately discard would certainly be much more efficient than\nhaving to scan for NUL, only to discard. But that does not\nsound as a plausible real-life scenario.\n"},{"id":"47380","messageId":"e5bfff550707141346q2eba4ab8ka1c85e8b5a2c1b1d@mail.gmail.com","threadId":"9036","inReplyTo":"7vodiehko7.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Add --show-size to git log to print message size","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-07-14T20:46:39Z","receivedAt":"2007-07-14T20:46:39Z","isPatch":true,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 7/14/07, Junio C Hamano wrote:\n>\n> \"size\" is a bit vague here. What if we later want to extend\n> things so that you can ask for the entire log entry size\n> including the patch output part (I am not saying that would be\n> an easy change --- I am more worried about the stability of the\n> external interface). So is --show-\"size\". \"message-size\" would\n> have been a bit easier to swallow, but I sense the problem runs\n> deeper.\n\nWhat about --section-sizes?\n\nYou can add in the output line all the sizes you want, message, patch\nand future extensions separated by a space. An example output for\nmessage and patch sizes.\n\nsizes 456 565\\n\n\nOr, as a stream friendly alternative (and also more elegant) you can\noutput 'section size' before each section, so as example\n\ncommit d9e940....\nsection size 456\n< log header and message body>\nsection size 565\n\nsection size 232\n\n\n\n> I have a more basic question. If you are reading from non \"-p\"\n> output, where do you exactly have the wasted cycles in your\n> reader's processing?\n\nqgit loading works like this:\n\ngit log output is read as a series of big binary chunks by a Qt\nlibrary function that calls read(), these chunks are read each one in\na different buffer and there they stay for all the application life\ntime (or until a data refresh), so there is no copy of data in qgit,\nthe buffers are allocated and the pointers passed to read(), that's\nall.\n\nIt's a kind of software DMA ;-)\n\nThe only information that qgit needs to infere at startup is where to\nfind the first line of each commit, for parent information and\nrevision's counting, all the other data is read and consumed only on\ndemand, i.e. for showing to user, but because only the screen visible\npart of the list is needed, data is read from these buffers and parsed\n*in small chunks* and only when user scrolls the view.\n\nThe problem is that to get the first line of each revision the message\nboundaries of _all_ the commits must be known/found.\n\nBecause currently there is no message size information the application have to:\n\n-get the offset of commit first line\n-try to find the delimiting '\\0' if existing (binary chunks could be\ntruncated at any point)\n-get the offset of commit first line of next revision\n-and so on for all the revisions\n\nFinding the delimiting '\\0' it means to loop across the whole buffers\nand _this_ is the expensive and not needed part. If just after the\nfirst line would be possible to point to the beginning of the next\nrevision this seeking for '\\0' would be not necessary anymore.\n\nWhen user asks for data of revision 'x' then because offset of\nrevision 'x' is known, application could just point to the correct\noffset in the correct data buffer and parse out the (small) needed\ninfo.\n\nHope I have explained clearly enough, I have some problems writing in\nat late evening ;-)\n\n\nMarco\n"},{"id":"47409","messageId":"20070715093529.GD2568@steel.home","threadId":"9036","inReplyTo":"e5bfff550707141346q2eba4ab8ka1c85e8b5a2c1b1d@mail.gmail.com","subject":"Re: [PATCH] Add --show-size to git log to print message size","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-07-15T09:35:29Z","receivedAt":"2007-07-15T09:35:29Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Marco Costalba, Sat, Jul 14, 2007 22:46:39 +0200:\n> Finding the delimiting '\\0' it means to loop across the whole buffers\n> and _this_ is the expensive and not needed part. If just after the\n\nIt is _not_ expensive. It could be made expensive, though. By using\nQString and QByteArray, for instance.\n\n> first line would be possible to point to the beginning of the next\n> revision this seeking for '\\0' would be not necessary anymore.\n\nBut this will make your reading different: you have to handle the case\nwhen the next revision is not _fully_ read in yet, but you already\nknow its size.\n\n> Hope I have explained clearly enough, I have some problems writing in\n> at late evening ;-)\n\nP.S. BTW, why do you have some 20 source files marked executable in\nyour qgit4 repository?\n"},{"id":"47411","messageId":"e5bfff550707150306t3196f723ia3071ac301fb3f24@mail.gmail.com","threadId":"9036","inReplyTo":"20070715093529.GD2568@steel.home","subject":"Re: [PATCH] Add --show-size to git log to print message size","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-07-15T10:06:53Z","receivedAt":"2007-07-15T10:06:53Z","isPatch":true,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 7/15/07, Alex Riesen wrote:\n> Marco Costalba, Sat, Jul 14, 2007 22:46:39 +0200:\n> > Finding the delimiting '\\0' it means to loop across the whole buffers\n> > and _this_ is the expensive and not needed part. If just after the\n>\n> It is _not_ expensive. It could be made expensive, though. By using\n> QString and QByteArray, for instance.\n>\n\nThe searching we are talking about is this (Rev::indexData() in\ngit_startup.cpp):\n\nint end = ba.indexOf('\\0', idx); // this is the slowest find\n\nthe starting point 'idx' is at the beginning of the log message.\n\n\nQt implemantation of indexOf() is this (src/corelib/tools/qbytearray.cpp):\n\nint QByteArray::indexOf(char ch, int from) const\n{\n if (from < 0)\n from = qMax(from + d->size, 0);\n if (from < d->size) {\n const char *n = d->data + from - 1;\n const char *e = d->data + d->size;\n while (++n != e)\n if (*n == ch)\n return n - d->data;\n }\n return -1;\n}\n\nHope this clears any doubts regarding (supposed) slowness of Qt classes.\n\n> > first line would be possible to point to the beginning of the next\n> > revision this seeking for '\\0' would be not necessary anymore.\n>\n> But this will make your reading different: you have to handle the case\n> when the next revision is not _fully_ read in yet, but you already\n> know its size.\n>\n\nReading and creating revision is made as a streaming, it means that\nwhen there is new data from git a new Rev struct (well it's a class\nindeed, but there's no diference) is created and populated with index\ndata: offset of the rev, parents number, offset of log message and so\non.\n\nIf, *while parsing the data* a truncated rev is found (we are at EOF\nand no '\\0' is found) the whole rev is discarded and deleted, we wait\nfor some more data and restart the process.\n\nBecause the above event is quite rare given the size of the buffers\nwhere git row data is stored, no really loss of speed occurs and we\nhave the (big) advantage of indexing *while* searching for '\\0', so to\nscan data only once.\n\nThis is how it works now.\n\nWith the proposed patch will be easier to find a truncated rev,\nbecause as soon as we know the rev size, after reading it from the\nstream, we check:\n\n if (revision_offset + size > byte_array_size)\n truncated_rev;\n\n\n>\n> P.S. BTW, why do you have some 20 source files marked executable in\n> your qgit4 repository?\n>\n\nImporting from Windows: ntfs does not handles file attributes\ncorrectly, I should clean up permissions but I'm lazy ;-)\n\n\nMarco\n\nP.S: I have an experimental branch where the above is implemented, I\ncannot publish now because it requires the --show-size change in git,\nbut after initial testing I have found that with the above applied the\noverhead of qgit on git-log it's about of only 16%.\n\nIt means that if git-log runs in say 3 seconds (warm cache), qgit with\nthe same git log arguments runs in about 3.5 seconds.\n\nWith cold cache overhead is also less because disk access is accounted\non the git side ;-)\n"},{"id":"47413","messageId":"20070715104858.GG2568@steel.home","threadId":"9036","inReplyTo":"e5bfff550707150306t3196f723ia3071ac301fb3f24@mail.gmail.com","subject":"Re: [PATCH] Add --show-size to git log to print message size","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-07-15T10:48:58Z","receivedAt":"2007-07-15T10:48:58Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Marco Costalba, Sun, Jul 15, 2007 12:06:53 +0200:\n> \n> Hope this clears any doubts regarding (supposed) slowness of Qt classes.\n\nNo, it does not. Look at the implementation of memchr.\n"},{"id":"47415","messageId":"e5bfff550707150432v780d8361yba2fc729504d5b73@mail.gmail.com","threadId":"9036","inReplyTo":"20070715104858.GG2568@steel.home","subject":"Re: [PATCH] Add --show-size to git log to print message size","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-07-15T11:32:55Z","receivedAt":"2007-07-15T11:32:55Z","isPatch":true,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 7/15/07, Alex Riesen wrote:\n> Marco Costalba, Sun, Jul 15, 2007 12:06:53 +0200:\n> >\n> > Hope this clears any doubts regarding (supposed) slowness of Qt classes.\n>\n> No, it does not. Look at the implementation of memchr.\n>\n\nIf this is the implementation you refer:\nhttp://www.google.com/codesearch?hl=it&q=+lang:c+license:gpl+package:libc+memchr+show:6Tvt4_C8w_Q:Sdpf5XO0rrM:Emqlj8d07Ns&sa=N&cd=4&ct=rc&cs_p=http://ftp.gnu.org/gnu/glibc/glibc-2.2.1.tar.gz&cs_f=glibc-2.2.1/sysdeps/i386/bits/string.h#a0\n\nI would say that I would prefer to avoid assemply and Qt libs seems to\ndo the same, perhaps for portability, but it's only a guess.\n\nAnyway with the proposed patch to git you don't need assembly at all\n(to me it's would seem an overkill)\n\nMarco\n"},{"id":"47420","messageId":"e5bfff550707150529l7e9bdd9fu253d38f99d4d2ed7@mail.gmail.com","threadId":"9036","inReplyTo":"e5bfff550707150432v780d8361yba2fc729504d5b73@mail.gmail.com","subject":"Re: [PATCH] Add --show-size to git log to print message size","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-07-15T12:29:04Z","receivedAt":"2007-07-15T12:29:04Z","isPatch":true,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"To further push for git patch, please check this from current linux tree:\n\ngit log --parents --pretty=raw -z -r -p c4201214\n\nAs you can see the diff contains a '\\0' value (actually removed by the patch).\n\nqgit of course fails, as any tool based on parsing '\\0' delimiting\ncharacter records. If the size of the patch was explicitly given\ninstead no fail will occur.\n\nMarco\n"},{"id":"47421","messageId":"20070715083529.6855a858.seanlkml@sympatico.ca","threadId":"9036","inReplyTo":"e5bfff550707150529l7e9bdd9fu253d38f99d4d2ed7@mail.gmail.com","subject":"Re: [PATCH] Add --show-size to git log to print message size","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2007-07-15T12:35:29Z","receivedAt":"2007-07-15T12:35:29Z","isPatch":true,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sun, 15 Jul 2007 14:29:04 +0200\n\"Marco Costalba\" wrote:\n\n> To further push for git patch, please check this from current linux tree:\n> \n> git log --parents --pretty=raw -z -r -p c4201214\n> \n> As you can see the diff contains a '\\0' value (actually removed by the patch).\n> \n> qgit of course fails, as any tool based on parsing '\\0' delimiting\n> character records. If the size of the patch was explicitly given\n> instead no fail will occur.\n> \n\nIf you only look for ^\\0 (ie. first position only) the parsing should\nbe okay. Not that it helps with the performance issue you're trying\nto address.\n\nSean\n"},{"id":"47434","messageId":"e5bfff550707150758h7a9e893frb068d4a9508bc3b2@mail.gmail.com","threadId":"9036","inReplyTo":"20070715083529.6855a858.seanlkml@sympatico.ca","subject":"Re: [PATCH] Add --show-size to git log to print message size","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-07-15T14:58:16Z","receivedAt":"2007-07-15T14:58:16Z","isPatch":true,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 7/15/07, Sean wrote:\n>\n> If you only look for ^\\0 (ie. first position only) the parsing should\n> be okay. Not that it helps with the performance issue you're trying\n> to address.\n>\nrevisions are streamed, there is only one first revision, all the\nothers are linked togheter in a big stream.\n\nActually I ended up looking for the character after the '\\0' (if any)\nto be 'c' that is the beginning of \"commit .....\" but it's a bit\nhacky.\n\n\nMarco\n"},{"id":"47436","messageId":"20070715110415.33692142.seanlkml@sympatico.ca","threadId":"9036","inReplyTo":"e5bfff550707150758h7a9e893frb068d4a9508bc3b2@mail.gmail.com","subject":"Re: [PATCH] Add --show-size to git log to print message size","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2007-07-15T15:04:15Z","receivedAt":"2007-07-15T15:04:15Z","isPatch":true,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sun, 15 Jul 2007 16:58:16 +0200\n\"Marco Costalba\" wrote:\n\n> On 7/15/07, Sean wrote:\n> >\n> > If you only look for ^\\0 (ie. first position only) the parsing should\n> > be okay. Not that it helps with the performance issue you're trying\n> > to address.\n> >\n> revisions are streamed, there is only one first revision, all the\n> others are linked togheter in a big stream.\n\nRight, but how does that alter the notion that ^\\0 is the safe way to\ntest for the \"real\" NUL terminator?\n\n> Actually I ended up looking for the character after the '\\0' (if any)\n> to be 'c' that is the beginning of \"commit .....\" but it's a bit\n> hacky.\n\nMuch more hacky than just testing for ^\\0. AFAIU, the NUL is\nguaranteed to come at the start of the line and _all_ other NUL\ncharacters are guaranteed to appear somewhere else. Your current\ntest will fail if a \"c\" happens to follow NUL in the patch text.\n\nSean\n"},{"id":"47439","messageId":"e5bfff550707150858i1825e01clf0897ad4db319373@mail.gmail.com","threadId":"9036","inReplyTo":"20070715110415.33692142.seanlkml@sympatico.ca","subject":"Re: [PATCH] Add --show-size to git log to print message size","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-07-15T15:58:21Z","receivedAt":"2007-07-15T15:58:21Z","isPatch":true,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 7/15/07, Sean wrote:\n>\n> characters are guaranteed to appear somewhere else. Your current\n> test will fail if a \"c\" happens to follow NUL in the patch text.\n>\n\nYes sir, I agree with you 100%\n\nThe real issue IMHO is that a 'delimiting character' should not appear\nin the content that it is trying to delimit. That's all the point\naround this thing. If a real 'delimiting character' does not exist\nbecause the content is free perhaps we should find a way to understand\nwhen we are at revision boundaries. The simplest (and most efficient)\nway is to know the size of the message in advance.\n\nAlso if git log filters out the '\\0' chars in the content it is\nsuboptimal because we could miss to see we have a '\\0' in content. BTW\nthe above mentioned patch in Linux tree was all around removing that\ngarbage '\\0'. If diff output was filtered out perhaps the author could\nhave missed that patch opportunity.\n\nMarco\n\nBTW, perhaps I'm retarded, but I fail to see what to search for with ^\\0.\n\nAs example if I have this output:\n\n\n Signed-off-by: Steven Whitehouse \n\ndiff --git a/fs/gfs2/rgrp.c b/fs/gfs2/rgrp.c\nindex fd3fd90..36c523d 100644\n--- a/fs/gfs2/rgrp.c\n+++ b/fs/gfs2/rgrp.c\n@@ -444,7 +444,6 @@ static int compute_bitstructs(struct gfs2_rgrpd *rgd)\n }\n\n /**\n-^@\n * gfs2_ri_total - Total up the file system space, according to the rindex.\n *\n */\n^@commit 8fb68595d508fd30ec90939572484b263600376c\nfad59c1390045b5adb7c7249ec4e77e0f868aca5\ntree 218a457675c111e2224fb57998d38e45d5786bd1\nparent fad59c1390045b5adb7c7249ec4e77e0f868aca5\n\n\nWhat should I search for to find the revision boundary? \"\\n\\0\" ? is\nthis that you mean with ^\\0\n"},{"id":"47441","messageId":"20070715121600.792982ef.seanlkml@sympatico.ca","threadId":"9036","inReplyTo":"e5bfff550707150858i1825e01clf0897ad4db319373@mail.gmail.com","subject":"Re: [PATCH] Add --show-size to git log to print message size","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2007-07-15T16:16:00Z","receivedAt":"2007-07-15T16:16:00Z","isPatch":true,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sun, 15 Jul 2007 17:58:21 +0200\n\"Marco Costalba\" wrote:\n\n> What should I search for to find the revision boundary? \"\\n\\0\" ? is\n> this that you mean with ^\\0\n\nEssentially yes. That pattern will never appear inside the comment\nor patch text because both sections are always indented. So in the\nexample you cite, \"\\n\\0\" would match the proper terminator, and the\n\"\\n-\\0\" NUL would be ignored.\n\nSean\n"},{"id":"47442","messageId":"e5bfff550707150927l745926f0nab04ad82dff913@mail.gmail.com","threadId":"9036","inReplyTo":"20070715121600.792982ef.seanlkml@sympatico.ca","subject":"Re: [PATCH] Add --show-size to git log to print message size","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-07-15T16:27:41Z","receivedAt":"2007-07-15T16:27:41Z","isPatch":true,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 7/15/07, Sean wrote:\n> On Sun, 15 Jul 2007 17:58:21 +0200\n> \"Marco Costalba\" wrote:\n>\n> > What should I search for to find the revision boundary? \"\\n\\0\" ? is\n> > this that you mean with ^\\0\n>\n> Essentially yes. That pattern will never appear inside the comment\n> or patch text because both sections are always indented. So in the\n> example you cite, \"\\n\\0\" would match the proper terminator, and the\n> \"\\n-\\0\" NUL would be ignored.\n>\n\nBut your scheme does not fail if the patch is not \\n terminated ?\n\nIt can happen if the patch adds lines at the end of a file and the\nlast line is not \\n terminated.\n\nIn this case your scheme seems to miss the good next revision boundary.\n\n\nMarco\n"},{"id":"47443","messageId":"20070715123422.9a431506.seanlkml@sympatico.ca","threadId":"9036","inReplyTo":"e5bfff550707150927l745926f0nab04ad82dff913@mail.gmail.com","subject":"Re: [PATCH] Add --show-size to git log to print message size","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2007-07-15T16:34:22Z","receivedAt":"2007-07-15T16:34:22Z","isPatch":true,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sun, 15 Jul 2007 18:27:41 +0200\n\"Marco Costalba\" wrote:\n\n> But your scheme does not fail if the patch is not \\n terminated ?\n\nI'm pretty sure there is always a preceding end-of-line marker,\nbefore the terminating NUL; although i haven't broken down and\nread the code yet.\n\n> It can happen if the patch adds lines at the end of a file and the\n> last line is not \\n terminated.\n> \n> In this case your scheme seems to miss the good next revision boundary.\n> \n\nJust tested this case here with \"git log --parents --pretty=raw -z -r -p\"\nand git prints out: \"\\ No newline at end of file\" followed by a newline\nand then the NUL.\n\nSean\n"},{"id":"47444","messageId":"e5bfff550707150954j6b1fcf6fs66b19d76db8461b1@mail.gmail.com","threadId":"9036","inReplyTo":"20070715123422.9a431506.seanlkml@sympatico.ca","subject":"Re: [PATCH] Add --show-size to git log to print message size","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-07-15T16:54:16Z","receivedAt":"2007-07-15T16:54:16Z","isPatch":true,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 7/15/07, Sean wrote:\n>\n> Just tested this case here with \"git log --parents --pretty=raw -z -r -p\"\n> and git prints out: \"\\ No newline at end of file\" followed by a newline\n> and then the NUL.\n>\n\nThanks. I think I will use your scheme so. But I really hope it's a\ntemporary workaround before git prints sizes with messages.\n\nThanks\nMarco\n"},{"id":"47446","messageId":"alpine.LFD.0.999.0707151110520.20061@woody.linux-foundation.org","threadId":"9036","inReplyTo":"e5bfff550707150529l7e9bdd9fu253d38f99d4d2ed7@mail.gmail.com","subject":"Re: [PATCH] Add --show-size to git log to print message size","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-07-15T18:14:30Z","receivedAt":"2007-07-15T18:14:30Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 15 Jul 2007, Marco Costalba wrote:\n>\n> To further push for git patch, please check this from current linux tree:\n> \n> git log --parents --pretty=raw -z -r -p c4201214\n> \n> As you can see the diff contains a '\\0' value (actually removed by the patch).\n\nSo arguably maybe we should have turned that patch into a binary patch, \nbut then it would have been really hard to read, and GNU patch and friends \ncouldn't have read it.\n\nSo I think a better option would be:\n\n> qgit of course fails, as any tool based on parsing '\\0' delimiting\n> character records. If the size of the patch was explicitly given\n> instead no fail will occur.\n\nYou have an alternate fix, namely to only look at the NUL character at \nnewline boundaries. Also, when it comes to \"git log\", you actually know \neven more: each commit begins with \"commit\".\n\nA patch will always be nicely line-oriented, and will never have a NULL at \nthe *beginning* of a line.\n\nSo you could actually make the parsing really strict, and look for the \nsequence\n\n\t'\\n\\0commit '\n\nand that's a very trustworthy delimeter.\n\nBut yes, you can have NUL-characters in the middle of patches.\n\n\t\tLinus\n"},{"id":"47448","messageId":"e5bfff550707151145w587c4c35l259516844c68e9aa@mail.gmail.com","threadId":"9036","inReplyTo":"alpine.LFD.0.999.0707151110520.20061@woody.linux-foundation.org","subject":"Re: [PATCH] Add --show-size to git log to print message size","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-07-15T18:45:38Z","receivedAt":"2007-07-15T18:45:38Z","isPatch":true,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 7/15/07, Linus Torvalds wrote:\n>\n> So you could actually make the parsing really strict, and look for the\n> sequence\n>\n> '\\n\\0commit '\n>\n> and that's a very trustworthy delimeter.\n>\n\nThanks to you and Sean for the hint, anyhow I would wish the message\nsize patch applied if it is possible and there are no drawbacks. Tool\nthat parses git-log output would benefit form that and the impact (in\ncode lines) is very low and also does not change anything if not\nactivated.\n\nThanks\nMarco\n"},{"id":"47537","messageId":"e5bfff550707160504p52770227l9af66aa750d9efd6@mail.gmail.com","threadId":"9036","inReplyTo":"7vodiehko7.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Add --show-size to git log to print message size","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-07-16T12:04:35Z","receivedAt":"2007-07-16T12:04:35Z","isPatch":true,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 7/14/07, Junio C Hamano wrote:\n> \"Marco Costalba\" writes:\n>\n>\n> \"size\" is a bit vague here. What if we later want to extend\n> things so that you can ask for the entire log entry size\n> including the patch output part (I am not saying that would be\n> an easy change --- I am more worried about the stability of the\n> external interface). So is --show-\"size\". \"message-size\" would\n> have been a bit easier to swallow, but I sense the problem runs\n> deeper.\n>\n\nI'm rewriting the patch + documentation cleaned up and with a\ndifferent option name (--show-log).\n\nCurrently the patch just include the log message because the diff\ncontent (-p option) is not buffered but is written with a combination\nof printf, puts, fputs, fwrite and putchar directly to stdout.\n\nMy question is, there is a way to get the quantity of bytes written to\nstdout before they are printed? I'm not an expert of C stdio library,\nso perhaps this is nonsense, but I was thinking of reading the size of\nstout buffer before to fflush() (I don't know if it is possible).\n\nIf it is not possible I have to give up in extending the scope of this\n'show me the size' patch to diff content and I will stick to the\nproper name --show-log.\n\nThanks\nMarco\n"},{"id":"47538","messageId":"81b0412b0707160531mad35ed4x4c89b2d6c6f5f707@mail.gmail.com","threadId":"9036","inReplyTo":"e5bfff550707160504p52770227l9af66aa750d9efd6@mail.gmail.com","subject":"Re: [PATCH] Add --show-size to git log to print message size","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-07-16T12:31:36Z","receivedAt":"2007-07-16T12:31:36Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 7/16/07, Marco Costalba wrote:\n> Currently the patch just include the log message because the diff\n> content (-p option) is not buffered but is written with a combination\n> of printf, puts, fputs, fwrite and putchar directly to stdout.\n>\n> My question is, there is a way to get the quantity of bytes written to\n> stdout before they are printed? I'm not an expert of C stdio library,\n> so perhaps this is nonsense, but I was thinking of reading the size of\n> stout buffer before to fflush() (I don't know if it is possible).\n\nIt is not possible. Buffers can be flushed at any time (i.e. they are\nflushed when EOL reached and the output is a terminal for stdout).\n\nIt is also a bit unclear _why_ do you need the diff output. You don't\nshow it immediately anyway.\n"},{"id":"47570","messageId":"7v4pk444rd.fsf@assigned-by-dhcp.cox.net","threadId":"9036","inReplyTo":"81b0412b0707160531mad35ed4x4c89b2d6c6f5f707@mail.gmail.com","subject":"Re: [PATCH] Add --show-size to git log to print message size","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-16T17:50:30Z","receivedAt":"2007-07-16T17:50:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Alex Riesen\" writes:\n\n> On 7/16/07, Marco Costalba wrote:\n>> Currently the patch just include the log message because the diff\n>> content (-p option) is not buffered but is written with a combination\n>> of printf, puts, fputs, fwrite and putchar directly to stdout.\n>>\n>> My question is, there is a way to get the quantity of bytes written to\n>> stdout before they are printed? I'm not an expert of C stdio library,\n>> so perhaps this is nonsense, but I was thinking of reading the size of\n>> stout buffer before to fflush() (I don't know if it is possible).\n>\n> It is not possible. Buffers can be flushed at any time (i.e. they are\n> flushed when EOL reached and the output is a terminal for stdout).\n>\n> It is also a bit unclear _why_ do you need the diff output. You don't\n> show it immediately anyway.\n\nI'd say making --show-message-size option incompatible with diff output\nwould be good enough futureproofing for now.\n"},{"id":"47571","messageId":"e5bfff550707161050w5751c63fnfa86312c86eaa552@mail.gmail.com","threadId":"9036","inReplyTo":"7vodiehko7.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Add --show-size to git log to print message size","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-07-16T17:50:58Z","receivedAt":"2007-07-16T17:50:58Z","isPatch":true,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 7/14/07, Junio C Hamano wrote:\n>\n> The current code spits out a log message after formatting it in\n> its entirety in core, so we happen to have its size upfront.\n> Having to say the size upfront means we close the door for\n> alternative implementations that stream the log formatting\n> processing.\n>\n\nThis is a better named patch that try also to easy your correct point\nabout alternative implementations, in particular a value of zero is\nreserved in case git is unable to satisfy the request, so that tools\ncan fallback on standard '\\0' searching.\n\nAfter inspecting diff.c code I made up my mind only log message can be\nsized upfront, diff ocntent is printed by a bunch of printf, fwrite,\nfputs, putchar and so on and it's impossible to know the size in\nadvance.\n\n------------------- cut -------------------\n\nSubject: [PATCH] Add --log-size to git log to print message size\n\nPrint message size just before the corresponding message.\n\nBecause git log output is normally read incrementally by\nporcelain tools, if message size is ignored then an\nexpensive seek of a delimiting char, as example '\\0'\nmust be done when parsing the output stream.\n\nWith this patch it is possible to avoid an otherwise\nmandatory seek for '\\0' starting from the beginning\nof log body.\n\nIn case it is not possible to know the size upfront\nsize value is set to zero.\n\nSigned-off-by: Marco Costalba \n---\n Documentation/git-log.txt | 5 +++++\n log-tree.c | 3 +++\n revision.c | 4 ++++\n revision.h | 1 +\n 4 files changed, 13 insertions(+), 0 deletions(-)\n\ndiff --git a/Documentation/git-log.txt b/Documentation/git-log.txt\nindex 63c1dbe..b539f50 100644\n--- a/Documentation/git-log.txt\n+++ b/Documentation/git-log.txt\n@@ -64,6 +64,11 @@ include::pretty-options.txt[]\n --follow::\n \tContinue listing the history of a file beyond renames.\n\n+--log-size::\n+\tBefore the log message print out its size in bytes. Intended\n+\tmainly for porcelain tools consumption. If git is unable to\n+\tproduce a valid value size is set to zero.\n+\n ...::\n \tShow only commits that affect the specified paths.\n\ndiff --git a/log-tree.c b/log-tree.c\nindex 8624d5a..2dc6b1b 100644\n--- a/log-tree.c\n+++ b/log-tree.c\n@@ -295,6 +295,9 @@ void show_log(struct rev_info *opt,\n \tif (opt->add_signoff)\n \t\tlen = append_signoff(&msgbuf, &msgbuf_len, len,\n \t\t\t\t opt->add_signoff);\n+ \tif (opt->show_log_size)\n+\t\tprintf(\"log size %i\\n\", len);\n+\n \tprintf(\"%s%s%s\", msgbuf, extra, sep);\n \tfree(msgbuf);\n }\ndiff --git a/revision.c b/revision.c\nindex 28b5f2e..f1cbb1f 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -1149,6 +1149,10 @@ int setup_revisions(int argc, const\n \t\t\t\t\tdie(\"unknown date format %s\", arg);\n \t\t\t\tcontinue;\n \t\t\t}\n+\t\t\tif (!strcmp(arg, \"--log-size\")) {\n+\t\t\t\trevs->show_log_size = 1;\n+\t\t\t\tcontinue;\n+\t\t\t}\n\n \t\t\t/*\n \t\t\t * Grepping the commit log\ndiff --git a/revision.h b/revision.h\nindex f46b4d5..98a0a8f 100644\n--- a/revision.h\n+++ b/revision.h\n@@ -81,6 +81,7 @@ struct rev_info {\n \tconst char\t*log_reencode;\n \tconst char\t*subject_prefix;\n \tint\t\tno_inline;\n+\tint\t\tshow_log_size;\n\n \t/* Filter by commit log message */\n \tstruct grep_opt\t*grep_filter;\n-- \n1.5.3.rc2-dirty\n"},{"id":"47573","messageId":"e5bfff550707161055i2f12b858n7be155765fb664@mail.gmail.com","threadId":"9036","inReplyTo":"7v4pk444rd.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Add --show-size to git log to print message size","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-07-16T17:55:26Z","receivedAt":"2007-07-16T17:55:26Z","isPatch":true,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 7/16/07, Junio C Hamano wrote:\n>\n> I'd say making --show-message-size option incompatible with diff output\n> would be good enough futureproofing for now.\n>\nOooops, I didn't see your post.\n\nI agree 100%, please tell me if doc it's clear enough or it would be\nbetter to clarify that \"message log\" it means only message and no diff\ncontent.\n\nMarco\n"},{"id":"47575","messageId":"e5bfff550707161102n3b6da174i7bbff64e1739a1b2@mail.gmail.com","threadId":"9036","inReplyTo":"e5bfff550707161055i2f12b858n7be155765fb664@mail.gmail.com","subject":"Re: [PATCH] Add --show-size to git log to print message size","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-07-16T18:02:39Z","receivedAt":"2007-07-16T18:02:39Z","isPatch":true,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 7/16/07, Marco Costalba wrote:\n> On 7/16/07, Junio C Hamano wrote:\n> >\n> > I'd say making --show-message-size option incompatible with diff output\n> > would be good enough futureproofing for now.\n> >\n> Oooops, I didn't see your post.\n>\n> I agree 100%, please tell me if doc it's clear enough or it would be\n> better to clarify that \"message log\" it means only message and no diff\n> content.\n>\n\nSorry to bother you again, but my English is very bad and I would like\nto be clear.\n\nWhen i say no diff content I mean that git log --log-size -p it's a\nperfect valid command but --log-size will make git print the size of\n_only_ the log part, it means from the line after \"log size xxx\\n\"\nuntil the end of log message that can be '\\0' (if no diff) or the\nbeginning of diff part.\n\nSorry to be pedantic.\n\nMarco\n"},{"id":"47602","messageId":"7vveck2cvs.fsf@assigned-by-dhcp.cox.net","threadId":"9036","inReplyTo":"e5bfff550707161102n3b6da174i7bbff64e1739a1b2@mail.gmail.com","subject":"Re: [PATCH] Add --show-size to git log to print message size","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-16T22:37:59Z","receivedAt":"2007-07-16T22:37:59Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Marco Costalba\" writes:\n\n> On 7/16/07, Marco Costalba wrote:\n>> On 7/16/07, Junio C Hamano wrote:\n>> >\n>> > I'd say making --show-message-size option incompatible with diff output\n>> > would be good enough futureproofing for now.\n>> >\n>> Oooops, I didn't see your post.\n>>\n>> I agree 100%, please tell me if doc it's clear enough or it would be\n>> better to clarify that \"message log\" it means only message and no diff\n>> content.\n>>\n>\n> Sorry to bother you again, but my English is very bad and I would like\n> to be clear.\n>\n> When i say no diff content I mean that git log --log-size -p it's a\n> perfect valid command but --log-size will make git print the size of\n> _only_ the log part, it means from the line after \"log size xxx\\n\"\n> until the end of log message that can be '\\0' (if no diff) or the\n> beginning of diff part.\n\nWhat I originally meant with my comment was to _error_ out if\nthe user says \"git log --log-size -p\" (or \"git show --log-size\"\nwithout \"-s\").\n\nBut I guess it is probably fine, as long as it is crystal clear\nto the users that we do not do size for non log part. I still\nhave this nagging feeling that this is an ugly workaround for Qt\nlibrary's programming interface, though...\n"},{"id":"47619","messageId":"200707170849.35842.andyparkins@gmail.com","threadId":"9036","inReplyTo":"e5bfff550707140952hb60735bi95a4f03636c4aa99@mail.gmail.com","subject":"Re: [PATCH] Add --show-size to git log to print message size","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-07-17T07:49:33Z","receivedAt":"2007-07-17T07:49:33Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Saturday 2007 July 14, Marco Costalba wrote:\n> Print message size just before the corresponding message\n> to speedup the parsing by scripts/porcelains tools.\n\nDoes this really give a speedup?\n\nI'd be surprised, as long as the parse is being done during the output from \ngit using the QProcess::readyRead() signal once and only once, then git is \nthe bottle neck. Parsing the stream is almost trivial in comparison to the \nwork that git is doing.\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"47644","messageId":"e5bfff550707170936kcd0c001nb4c4a90baacf4275@mail.gmail.com","threadId":"9036","inReplyTo":"200707170849.35842.andyparkins@gmail.com","subject":"Re: [PATCH] Add --show-size to git log to print message size","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-07-17T16:36:15Z","receivedAt":"2007-07-17T16:36:15Z","isPatch":true,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 7/17/07, Andy Parkins wrote:\n>\n> Does this really give a speedup?\n>\n> I'd be surprised, as long as the parse is being done during the output from\n> git using the QProcess::readyRead() signal once and only once, then git is\n> the bottle neck. Parsing the stream is almost trivial in comparison to the\n> work that git is doing.\n>\n\nWell, it's not exactly from readyRead() but you are right, the bottle\nneck it's git.\n\nA bare:\ntime git log --parents --boundary --pretty=raw -z --log-size\n--topo-order HEAD > /dev/null\n\ngives on linux and git repositories\ngit 960ms\nlinux 6920ms\n\nInstead qgit gives, with the same command:\n\nWITHOUT --log-size patch\ngit 1170ms (+21%)\nlinux 7942ms (+15%)\n\n\nWITH --log-size patch\ngit 1125ms (+17%)\nlinux 7820ms (+13%)\n\nI don't know why overhead on Linux is less, probably on small repos\nthe GUI part of qgit that you can consider more or less a constant\ntime weights more regarding parsing.\n\n\nMarco\n"},{"id":"48538","messageId":"7vabtlf7tf.fsf@assigned-by-dhcp.cox.net","threadId":"9036","inReplyTo":"e5bfff550707140952hb60735bi95a4f03636c4aa99@mail.gmail.com","subject":"Re: [PATCH] Add --show-size to git log to print message size","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-25T04:03:56Z","receivedAt":"2007-07-25T04:03:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I've been re-reviewing recent patches, and this is one of them.\nHowever, I am wondering if this is an intended behaviour...\n\n: git.git master; ./git-log --log-size --abbrev-commit --pretty=oneline \\\n ko/master..master\n9d468ac... log size 47\nAdd --log-size to git log to print message size\nca193cf... log size 40\ngit am: skip pine's internal folder data\nd1cc130... log size 48\nTeach git-commit about commit message templates.\naf66366... log size 41\nTeach approxidate() to understand \"never\"\n7b69b87... log size 64\ngit log -g: Complain, but do not fail, when no reflogs are there\n2d8ae40... log size 49\nsend-email: Update regex parsing for pine aliases\nf836f1a... log size 40\ncvsexportcommit: avoid racy CVS problem.\n1843d8d... log size 53\ncleanup unpack-trees.c: shrink struct tree_entry_list\n24d0063... log size 56\nfilter-branch: fix dash complaining about \"Missing '))'\"\n3473e7d... log size 56\ngitweb: More detailed error messages for snapshot format\n93c22ee... log size 47\ngit.el: Support for incremental status updates.\n"},{"id":"48549","messageId":"e5bfff550707250238i4fd7926en4c924a0debbb9a3c@mail.gmail.com","threadId":"9036","inReplyTo":"7vabtlf7tf.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Add --show-size to git log to print message size","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-07-25T09:38:01Z","receivedAt":"2007-07-25T09:38:01Z","isPatch":true,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 7/25/07, Junio C Hamano wrote:\n> I've been re-reviewing recent patches, and this is one of them.\n\nThanks for pushing to pu. Please tell me if you want me to send you a\npatch to update to what we have discussed, specifically using \"length\nunknown\" and changing the name to --show-lengths.\n\n> However, I am wondering if this is an intended behaviour...\n>\n> : git.git master; ./git-log --log-size --abbrev-commit --pretty=oneline \\\n> ko/master..master\n> 9d468ac... log size 47\n> Add --log-size to git log to print message size\n> ca193cf... log size 40\n\nWell, the patch should be used to speedup the parsing by tools because\nyou can skip big part of the record and jump directly to the beginning\nof the next one. So IMHO I don't see a lot of sense in using it\ntogether with --pretty=oneline.\n\nAnyway only default options should be guaranteed to behave correctly\nwith all the other options. In general, responsibility for what you\nsee on the screen it's on the tips of user's fingers. IMHO\nresponsibility of git is of not crashing and do not show incorrect\ninfo, not that the info should be useful.\n\nPaul, I don't know gitk and Tcl to being able to answer myself, but I\nwould like to know if this new option could be useful also for gitk.\n\nThis option, after the first line, gives the size of the following\npart of the record. Does this allow you to delay the parsing of the\nbiggest part of the commit record?\n\nAuthor name, date, log title, log message could be read only when it's\nneeded, so that after reading the first couple lines of a commit you\ncan point directly to the beginning of the next one skipping the rest.\n\nMarco\n"}]}