{"thread":{"id":"11357","subject":"Serious bug with pretty format strings & empty bodies?","startedAt":"2007-12-19T14:32:20Z","lastAt":"2007-12-22T15:48:21Z","messageCount":16,"participants":["Jonathan del Strother","René Scharfe","Alex Riesen","Johannes Schindelin","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"63770","messageId":"57518fd10712190632o490af924n61326fddf1819014@mail.gmail.com","threadId":"11357","inReplyTo":null,"subject":"Serious bug with pretty format strings & empty bodies?","fromName":"Jonathan del Strother","fromEmail":"maillist@steelskies.com","sentAt":"2007-12-19T14:32:20Z","receivedAt":"2007-12-19T14:32:20Z","isPatch":false,"sender":{"key":"jon.delstrother@bestbefore.tv","avatar":"https://gravatar.com/avatar/754e21ab701c00e2d21fc261187254c34b2a1c0b959d9ee5be1a295990be3081?d=mp&s=160"},"body":"I'm struggling to come up with a minimal test case that confirms this,\nbut I seem to be hitting a bug in the pretty string formatter when\ntrying to print bodies of commits that don't have bodies.\n\nFor example, on a private repository, I'm trying to print the subject\n& body of a commit. This particular commit doesn't actually have a\nbody, so I'm expecting to see this output :\n\n=================\ncommit 18d2480ab689b483ef1ebbdb3f7420904049ba0b\nTry to flush log files before terminating the app\n\n=================\n\nHowever, when I actually run the command, I get gibberish in place of %b :\n=================\n$ git rev-list -1- --pretty=format:\"%s%n%b\"\n18d2480ab689b483ef1ebbdb3f7420904049ba0b\ncommit 18d2480ab689b483ef1ebbdb3f7420904049ba0b\nTry to flush log files before terminating the app\ntree 57bc7cf30a10aee96251852125cf30fd2c81d7aa\nparent 04c833865828538315fcdf6e187da077869ce444\nauthor Jonathan del Strother 1197901755 +0000\ncommitter Jonathan del Strother 1197901755 +0000\n\nCheck that ThreadWorker's work method actually returns a value with\nmethod signatures\n=================\n\nSo here you can see that the full details of a different commit is\nappearing in place of the requested commit's (empty) body. Rerunning\nthe rev-list produces the same output - the same string appears in\nplace of %b every time, but it's different for each commit. Often you\nonly get a small fragment of another commit's message, rather than the\nfull commit as seen above.\n\nWhen I use --pretty=full, it works fine.\n\nThis appears in quite a few places in my repository's history.\nRepacking the repo semi-fixes it - I still get junk bodies, but not\nquite so many.\n\nIt doesn't always happen when a commit message body is empty, but I've\nnever seen it happen where the message body has something in.\n\nThis happens with both git 1.5.3.7 and 1.5.4.rc0.1162.g3bfea, though\nthe output is slightly different - the former has a number of\n markers in it. This is on OS X 10.5.1\n\n\nAny suggestions?\nCheers,\nJon\n"},{"id":"63788","messageId":"476962D5.3050409@lsrfire.ath.cx","threadId":"11357","inReplyTo":"57518fd10712190632o490af924n61326fddf1819014@mail.gmail.com","subject":"Re: Serious bug with pretty format strings & empty bodies?","fromName":"René Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2007-12-19T18:28:37Z","receivedAt":"2007-12-19T18:28:37Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Jonathan del Strother schrieb:\n> I'm struggling to come up with a minimal test case that confirms this,\n> but I seem to be hitting a bug in the pretty string formatter when\n> trying to print bodies of commits that don't have bodies.\n> \n> For example, on a private repository, I'm trying to print the subject\n> & body of a commit. This particular commit doesn't actually have a\n> body, so I'm expecting to see this output :\n> \n> =================\n> commit 18d2480ab689b483ef1ebbdb3f7420904049ba0b\n> Try to flush log files before terminating the app\n> \n> =================\n> \n> However, when I actually run the command, I get gibberish in place of %b :\n> =================\n> $ git rev-list -1- --pretty=format:\"%s%n%b\"\n> 18d2480ab689b483ef1ebbdb3f7420904049ba0b\n> commit 18d2480ab689b483ef1ebbdb3f7420904049ba0b\n> Try to flush log files before terminating the app\n> tree 57bc7cf30a10aee96251852125cf30fd2c81d7aa\n> parent 04c833865828538315fcdf6e187da077869ce444\n> author Jonathan del Strother 1197901755 +0000\n> committer Jonathan del Strother 1197901755 +0000\n> \n> Check that ThreadWorker's work method actually returns a value with\n> method signatures\n> =================\n> \n> So here you can see that the full details of a different commit is\n> appearing in place of the requested commit's (empty) body. Rerunning\n> the rev-list produces the same output - the same string appears in\n> place of %b every time, but it's different for each commit. Often you\n> only get a small fragment of another commit's message, rather than the\n> full commit as seen above.\n> \n> When I use --pretty=full, it works fine.\n> \n> This appears in quite a few places in my repository's history.\n> Repacking the repo semi-fixes it - I still get junk bodies, but not\n> quite so many.\n> \n> It doesn't always happen when a commit message body is empty, but I've\n> never seen it happen where the message body has something in.\n> \n> This happens with both git 1.5.3.7 and 1.5.4.rc0.1162.g3bfea, though\n> the output is slightly different - the former has a number of\n> markers in it. This is on OS X 10.5.1\n\nThat's strange. Could you check if this happens with e52a5de, too?\nThat's the commit that introduced --pretty=format. If it doesn't, could\nyou then please try to bisect the bug?\n\nHow many '' markers are there in the output of version 1.5.3.7\n(and e52a5de)? One per %b? Are they the only output or are they\ncombined with parts of unrelated commits, too?\n\nThanks,\nRené\n"},{"id":"63789","messageId":"20071219184457.GC3015@steel.home","threadId":"11357","inReplyTo":"57518fd10712190632o490af924n61326fddf1819014@mail.gmail.com","subject":"Re: Serious bug with pretty format strings & empty bodies?","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-12-19T18:44:57Z","receivedAt":"2007-12-19T18:44:57Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Jonathan del Strother, Wed, Dec 19, 2007 15:32:20 +0100:\n> I'm struggling to come up with a minimal test case that confirms this,\n> but I seem to be hitting a bug in the pretty string formatter when\n> trying to print bodies of commits that don't have bodies.\n\nI tried\n\n $ git init\n $ git rev-list --pretty=format:\"%s%n%b\" \\\n\t$(echo -n \"Test\" |git commit-tree $(git write-tree))\n\nbut it works. It is possible that the commit in question is created\nwith an older commit-tree code. Could you try\n\n git cat-file 18d2480ab689b483ef1ebbdb3f7420904049ba0b\n\n(or any other problematic commit) and post its output here?\nOr is the repo publised somewhere?\n"},{"id":"63809","messageId":"57518fd10712191437s6f192feds50d006fdfc624444@mail.gmail.com","threadId":"11357","inReplyTo":"20071219184457.GC3015@steel.home","subject":"Re: Serious bug with pretty format strings & empty bodies?","fromName":"Jonathan del Strother","fromEmail":"maillist@steelskies.com","sentAt":"2007-12-19T22:37:24Z","receivedAt":"2007-12-19T22:37:24Z","isPatch":false,"sender":{"key":"jon.delstrother@bestbefore.tv","avatar":"https://gravatar.com/avatar/754e21ab701c00e2d21fc261187254c34b2a1c0b959d9ee5be1a295990be3081?d=mp&s=160"},"body":"On Dec 19, 2007 6:44 PM, Alex Riesen wrote:\n> Could you try\n>\n> git cat-file 18d2480ab689b483ef1ebbdb3f7420904049ba0b\n>\n> (or any other problematic commit) and post its output here?\n\nYou mean git cat-file commit ... ?\nI get the normal output, but the problematic commits don't show a\nnewline character at the end of the cat-file output.\n\n\n> Or is the repo publised somewhere?\n\nAfraid not - it's private code.\n\n\nI'll try bisecting e52a5de tomorrow, see if that gets me anywhere.\n"},{"id":"63817","messageId":"4769A7FB.1070904@lsrfire.ath.cx","threadId":"11357","inReplyTo":"57518fd10712191437s6f192feds50d006fdfc624444@mail.gmail.com","subject":"Re: Serious bug with pretty format strings & empty bodies?","fromName":"René Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2007-12-19T23:23:39Z","receivedAt":"2007-12-19T23:23:39Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Jonathan del Strother schrieb:\n> On Dec 19, 2007 6:44 PM, Alex Riesen wrote:\n>> Could you try\n>>\n>> git cat-file 18d2480ab689b483ef1ebbdb3f7420904049ba0b\n>>\n>> (or any other problematic commit) and post its output here?\n> \n> You mean git cat-file commit ... ?\n> I get the normal output, but the problematic commits don't show a\n> newline character at the end of the cat-file output.\n\nJust a shot in the dark: does this patch on top of master make a difference?\n\ndiff --git a/pretty.c b/pretty.c\nindex 9db75b4..5f95a59 100644\n--- a/pretty.c\n+++ b/pretty.c\n@@ -412,7 +412,7 @@ static void parse_commit_header(struct format_commit_context *context)\n \t\tif (i == eol) {\n \t\t\tstate++;\n \t\t\t/* strip empty lines */\n-\t\t\twhile (msg[eol + 1] == '\\n')\n+\t\t\twhile (msg[eol] == '\\n' && msg[eol + 1] == '\\n')\n \t\t\t\teol++;\n \t\t} else if (!prefixcmp(msg + i, \"author \")) {\n \t\t\tcontext->author.off = i + 7;\n"},{"id":"63848","messageId":"57518fd10712200243o26641b3bjf9be3898a2f0c7e1@mail.gmail.com","threadId":"11357","inReplyTo":"476962D5.3050409@lsrfire.ath.cx","subject":"Re: Serious bug with pretty format strings & empty bodies?","fromName":"Jonathan del Strother","fromEmail":"maillist@steelskies.com","sentAt":"2007-12-20T10:43:40Z","receivedAt":"2007-12-20T10:43:40Z","isPatch":false,"sender":{"key":"jon.delstrother@bestbefore.tv","avatar":"https://gravatar.com/avatar/754e21ab701c00e2d21fc261187254c34b2a1c0b959d9ee5be1a295990be3081?d=mp&s=160"},"body":"On Dec 19, 2007 6:28 PM, René Scharfe wrote:\n> That's strange. Could you check if this happens with e52a5de, too?\n> That's the commit that introduced --pretty=format. If it doesn't, could\n> you then please try to bisect the bug?\n\nAs far as I can tell, e52a... never compiled - it's missing prefixcmp\nfrom git-compat-util.h, which doesn't get merged in till 8ab3e18.\nAnd yes, I still get junk output from that build. (Shame, I was\nlooking forward to trying out the bisect tool...)\n\n\n> How many '' markers are there in the output of version 1.5.3.7\n> (and e52a5de)? One per %b? Are they the only output or are they\n> combined with parts of unrelated commits, too?\n\nOnly one per %b, and where they appear, they're the only output.\nHowever, even with those builds, I get junk output in addition to the\n markers.\nThat is, with a format string of \"**%b**\", there are three possible outputs :\nThe correct one - eg **Added test for NSDictionary generator**\nThe unknown one - eg ****\nThe complete junk one - eg **n del\nStrothereb0d794bacc1761e8a0681e9b144c514702d9b7a**\n\nThe latter's 'body' is almost always terminated by an unprintable\ncharacter, which always seems to be 03.\n\n\nHmmm. I wonder if it's coincidence that I can only seem to spot this\nproblem in my repos that have been set up via submodule init...\n"},{"id":"63849","messageId":"57518fd10712200244o656c7f44j426cc71c89515de3@mail.gmail.com","threadId":"11357","inReplyTo":"4769A7FB.1070904@lsrfire.ath.cx","subject":"Re: Serious bug with pretty format strings & empty bodies?","fromName":"Jonathan del Strother","fromEmail":"maillist@steelskies.com","sentAt":"2007-12-20T10:44:12Z","receivedAt":"2007-12-20T10:44:12Z","isPatch":false,"sender":{"key":"jon.delstrother@bestbefore.tv","avatar":"https://gravatar.com/avatar/754e21ab701c00e2d21fc261187254c34b2a1c0b959d9ee5be1a295990be3081?d=mp&s=160"},"body":"On Dec 19, 2007 11:23 PM, René Scharfe wrote:\n> Jonathan del Strother schrieb:\n> > On Dec 19, 2007 6:44 PM, Alex Riesen wrote:\n> >> Could you try\n> >>\n> >> git cat-file 18d2480ab689b483ef1ebbdb3f7420904049ba0b\n> >>\n> >> (or any other problematic commit) and post its output here?\n> >\n> > You mean git cat-file commit ... ?\n> > I get the normal output, but the problematic commits don't show a\n> > newline character at the end of the cat-file output.\n>\n> Just a shot in the dark: does this patch on top of master make a difference?\n>\n> diff --git a/pretty.c b/pretty.c\n> index 9db75b4..5f95a59 100644\n> --- a/pretty.c\n> +++ b/pretty.c\n> @@ -412,7 +412,7 @@ static void parse_commit_header(struct format_commit_context *context)\n> if (i == eol) {\n> state++;\n> /* strip empty lines */\n> - while (msg[eol + 1] == '\\n')\n> + while (msg[eol] == '\\n' && msg[eol + 1] == '\\n')\n> eol++;\n> } else if (!prefixcmp(msg + i, \"author \")) {\n> context->author.off = i + 7;\n>\n\nNo luck with that, I'm afraid.\n"},{"id":"63850","messageId":"57518fd10712200246qdc1062btb5c20de946468995@mail.gmail.com","threadId":"11357","inReplyTo":"57518fd10712200243o26641b3bjf9be3898a2f0c7e1@mail.gmail.com","subject":"Re: Serious bug with pretty format strings & empty bodies?","fromName":"Jonathan del Strother","fromEmail":"maillist@steelskies.com","sentAt":"2007-12-20T10:46:15Z","receivedAt":"2007-12-20T10:46:15Z","isPatch":false,"sender":{"key":"jon.delstrother@bestbefore.tv","avatar":"https://gravatar.com/avatar/754e21ab701c00e2d21fc261187254c34b2a1c0b959d9ee5be1a295990be3081?d=mp&s=160"},"body":"> Hmmm. I wonder if it's coincidence that I can only seem to spot this\n> problem in my repos that have been set up via submodule init...\n\nIgnore that last bit, red herring.\n"},{"id":"63852","messageId":"57518fd10712200338m19c1def9n747dc9353ae41615@mail.gmail.com","threadId":"11357","inReplyTo":"4769A7FB.1070904@lsrfire.ath.cx","subject":"Re: Serious bug with pretty format strings & empty bodies?","fromName":"Jonathan del Strother","fromEmail":"maillist@steelskies.com","sentAt":"2007-12-20T11:38:25Z","receivedAt":"2007-12-20T11:38:25Z","isPatch":false,"sender":{"key":"jon.delstrother@bestbefore.tv","avatar":"https://gravatar.com/avatar/754e21ab701c00e2d21fc261187254c34b2a1c0b959d9ee5be1a295990be3081?d=mp&s=160"},"body":"I ended up trying to filter-branch my repository, see if I could come\nup with a version stripped of all our private code, suitable for\nmaking public. Disappointingly, filter-branch magically fixes all the\ncommits, even when simply run as \"git filter-branch HEAD\".\n\nHowever, looking at the rewritten repository vs the original, they\nshare a lot of commits, then diverge halfway through their history. I\ncan't see anything notable about the commit where they diverge, with\nthe exception that the rewritten commit has a newline after the\nsubject and the original doesn't. Neither has a commit message body.\n"},{"id":"63859","messageId":"476A5DFF.40803@lsrfire.ath.cx","threadId":"11357","inReplyTo":"57518fd10712200244o656c7f44j426cc71c89515de3@mail.gmail.com","subject":"Re: Serious bug with pretty format strings & empty bodies?","fromName":"René Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2007-12-20T12:20:15Z","receivedAt":"2007-12-20T12:20:15Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Jonathan del Strother schrieb:\n> On Dec 19, 2007 11:23 PM, René Scharfe wrote:\n>> Just a shot in the dark: does this patch on top of master make a difference?\n> No luck with that, I'm afraid.\n\nAnd how is this one?\n\nThe first chunk is the same as in the last try -- it guards against commit\nmessages ending with a NUL without a prior \\n _and_ being followed by a \\n\n(in memory which shouldn't be accessed by us at all as it doesn't belong to\nthe commit message). I guess that's quite rare.\n\nThe second chunk keeps the body offset from being incremented by the for\nloop if we've already found a terminating NUL.\n\ndiff --git a/pretty.c b/pretty.c\nindex 9db75b4..5b1078b 100644\n--- a/pretty.c\n+++ b/pretty.c\n@@ -412,7 +412,7 @@ static void parse_commit_header(struct format_commit_context *context)\n \t\tif (i == eol) {\n \t\t\tstate++;\n \t\t\t/* strip empty lines */\n-\t\t\twhile (msg[eol + 1] == '\\n')\n+\t\t\twhile (msg[eol] == '\\n' && msg[eol + 1] == '\\n')\n \t\t\t\teol++;\n \t\t} else if (!prefixcmp(msg + i, \"author \")) {\n \t\t\tcontext->author.off = i + 7;\n@@ -425,6 +425,8 @@ static void parse_commit_header(struct format_commit_context *context)\n \t\t\tcontext->encoding.len = eol - i - 9;\n \t\t}\n \t\ti = eol;\n+\t\tif (!msg[i])\n+\t\t\tbreak;\n \t}\n \tcontext->body_off = i;\n \tcontext->commit_header_parsed = 1;\n"},{"id":"63861","messageId":"Pine.LNX.4.64.0712201333010.14355@wbgn129.biozentrum.uni-wuerzburg.de","threadId":"11357","inReplyTo":"57518fd10712200338m19c1def9n747dc9353ae41615@mail.gmail.com","subject":"Re: Serious bug with pretty format strings & empty bodies?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-20T12:34:54Z","receivedAt":"2007-12-20T12:34:54Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 20 Dec 2007, Jonathan del Strother wrote:\n\n> I ended up trying to filter-branch my repository, see if I could come\n> up with a version stripped of all our private code, suitable for\n> making public. Disappointingly, filter-branch magically fixes all the\n> commits, even when simply run as \"git filter-branch HEAD\".\n> \n> However, looking at the rewritten repository vs the original, they\n> share a lot of commits, then diverge halfway through their history. I\n> can't see anything notable about the commit where they diverge, with\n> the exception that the rewritten commit has a newline after the\n> subject and the original doesn't. Neither has a commit message body.\n\nI do not see how Rene's patch could _not_ have fixed that problem.\n\nAs it is, I cannot even reproduce without that patch. This is what I was \ntrying:\n\n-- snip --\ndiff --git a/t/t4025-pretty-format.sh b/t/t4025-pretty-format.sh\nnew file mode 100644\nindex 0000000..2826bcb\n--- /dev/null\n+++ b/t/t4025-pretty-format.sh\n@@ -0,0 +1,23 @@\n+#!/bin/sh\n+\n+test_description='git pretty formats'\n+\n+. ./test-lib.sh\n+\n+test_expect_success 'setup' '\n+\n+\t: > file &&\n+\tgit add file &&\n+\ttree=$(git write-tree) &&\n+\tcommit=$(echo No newlin | tr \"\\\\012\" e | git commit-tree $tree) &&\n+\tgit update-ref HEAD $commit\n+\n+'\n+\n+test_expect_success 'format:%b' '\n+\n+\ttest -z \"$(git log -1 --pretty=format:%b)\"\n+\n+'\n+\n+test_done\n-- snap --\n\nSeems I cannot help any more, but at least this is a starting point to \ntry to reproduce.\n\nCiao,\nDscho\n"},{"id":"63862","messageId":"Pine.LNX.4.64.0712201336200.14355@wbgn129.biozentrum.uni-wuerzburg.de","threadId":"11357","inReplyTo":"476A5DFF.40803@lsrfire.ath.cx","subject":"Re: Serious bug with pretty format strings & empty bodies?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-20T12:37:13Z","receivedAt":"2007-12-20T12:37:13Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 20 Dec 2007, Ren? Scharfe wrote:\n\n> The second chunk keeps the body offset from being incremented by the for \n> loop if we've already found a terminating NUL.\n\nAh! I missed that one *writethisdownintothebook*\n\nThanks,\nDscho\n"},{"id":"63864","messageId":"57518fd10712200508x4b15f9acy10aed83a3cebeba@mail.gmail.com","threadId":"11357","inReplyTo":"476A5DFF.40803@lsrfire.ath.cx","subject":"Re: Serious bug with pretty format strings & empty bodies?","fromName":"Jonathan del Strother","fromEmail":"maillist@steelskies.com","sentAt":"2007-12-20T13:08:37Z","receivedAt":"2007-12-20T13:08:37Z","isPatch":false,"sender":{"key":"jon.delstrother@bestbefore.tv","avatar":"https://gravatar.com/avatar/754e21ab701c00e2d21fc261187254c34b2a1c0b959d9ee5be1a295990be3081?d=mp&s=160"},"body":"On Dec 20, 2007 12:20 PM, René Scharfe wrote:\n> Jonathan del Strother schrieb:\n> > On Dec 19, 2007 11:23 PM, René Scharfe wrote:\n> >> Just a shot in the dark: does this patch on top of master make a difference?\n> > No luck with that, I'm afraid.\n>\n> And how is this one?\n>\n> The first chunk is the same as in the last try -- it guards against commit\n> messages ending with a NUL without a prior \\n _and_ being followed by a \\n\n> (in memory which shouldn't be accessed by us at all as it doesn't belong to\n> the commit message). I guess that's quite rare.\n>\n> The second chunk keeps the body offset from being incremented by the for\n> loop if we've already found a terminating NUL.\n>\n> diff --git a/pretty.c b/pretty.c\n> index 9db75b4..5b1078b 100644\n> --- a/pretty.c\n> +++ b/pretty.c\n> @@ -412,7 +412,7 @@ static void parse_commit_header(struct format_commit_context *context)\n> if (i == eol) {\n> state++;\n> /* strip empty lines */\n> - while (msg[eol + 1] == '\\n')\n> + while (msg[eol] == '\\n' && msg[eol + 1] == '\\n')\n> eol++;\n> } else if (!prefixcmp(msg + i, \"author \")) {\n> context->author.off = i + 7;\n> @@ -425,6 +425,8 @@ static void parse_commit_header(struct format_commit_context *context)\n> context->encoding.len = eol - i - 9;\n> }\n> i = eol;\n> + if (!msg[i])\n> + break;\n> }\n> context->body_off = i;\n> context->commit_header_parsed = 1;\n>\n\nWinnar!\n\nYep, that seems to have fixed things. Wonder how I managed to get the\nnull into the commit message...\n"},{"id":"63914","messageId":"57518fd10712210247s2fcbbf61ke67bbdc0f5ffe70b@mail.gmail.com","threadId":"11357","inReplyTo":"57518fd10712200508x4b15f9acy10aed83a3cebeba@mail.gmail.com","subject":"Re: Serious bug with pretty format strings & empty bodies?","fromName":"Jonathan del Strother","fromEmail":"maillist@steelskies.com","sentAt":"2007-12-21T10:47:45Z","receivedAt":"2007-12-21T10:47:45Z","isPatch":false,"sender":{"key":"jon.delstrother@bestbefore.tv","avatar":"https://gravatar.com/avatar/754e21ab701c00e2d21fc261187254c34b2a1c0b959d9ee5be1a295990be3081?d=mp&s=160"},"body":"Has anyone actually managed to reproduce my problem? I've got\nmultiple repos here that show the problem in several commits, made by\ndifferent people. However, I can't actually come up with a way to\nreproduce it at will...\n\nI'd really like to see René's patch accepted as it seems to magically\nfix all my problems, but it's a bit hard to justify if I'm the only\none that's seeing these broken commit messages.\n"},{"id":"63986","messageId":"7vhcibyvh0.fsf@gitster.siamese.dyndns.org","threadId":"11357","inReplyTo":"57518fd10712210247s2fcbbf61ke67bbdc0f5ffe70b@mail.gmail.com","subject":"Re: Serious bug with pretty format strings & empty bodies?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-22T08:39:07Z","receivedAt":"2007-12-22T08:39:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Jonathan del Strother\" writes:\n\n> Has anyone actually managed to reproduce my problem? I've got\n> multiple repos here that show the problem in several commits, made by\n> different people. However, I can't actually come up with a way to\n> reproduce it at will...\n\nMarking an issue as a \"serious bug\" without giving enough\nmaterial for reproduction nor diagnosis tends to discourage\npeople from looking into it seriously, as the issue cannot be\neven judged if it is really serious. For example:\n\n On Dec 19, 2007 6:44 PM, Alex Riesen wrote:\n > Could you try\n >\n > git cat-file 18d2480ab689b483ef1ebbdb3f7420904049ba0b\n >\n > (or any other problematic commit) and post its output here?\n\n You mean git cat-file commit ... ?\n I get the normal output, but the problematic commits don't show a\n newline character at the end of the cat-file output.\n\n\"I get the normal output\" is not what Alex asked you to supply,\nnor would be sufficient information. There may be some\nabnormality in the commit object that you probably did not spot,\nbut Alex or other people may have been able to if you were\nactually posted its output here.\n\nI have been suspecting that there is a NUL in the middle of the\nmessage somehow (I know the lowest-level plumbing commit-tree\nallows any byte sequence in the log message if you worked hard\nenough), which the parser is not prepared to cope with, but we\nhaven't seen enough evidence to support nor refute that theory.\nWe do not have much to work from.\n\nOne thing I noticed funny in your original message was \"-1-\".\nIs it essential that the number is spelled incorrectly to\nreproduce this problem?\n\n $ git rev-list -1- --pretty=format:\"%s%n%b\"\n 18d2480ab689b483ef1ebbdb3f7420904049ba0b\n commit 18d2480ab689b483ef1ebbdb3f7420904049ba0b\n Try to flush log files before terminating the app\n tree 57bc7cf30a10aee96251852125cf30fd2c81d7aa\n parent 04c833865828538315fcdf6e187da077869ce444\n author Jonathan del Strother 1197901755 +0000\n committer Jonathan del Strother 1197901755 +0000\n\n Check that ThreadWorker's work method actually returns a value with\n method signatures\n"},{"id":"64000","messageId":"57518fd10712220748v188d769eo204fcc572993395e@mail.gmail.com","threadId":"11357","inReplyTo":"7vhcibyvh0.fsf@gitster.siamese.dyndns.org","subject":"Re: Serious bug with pretty format strings & empty bodies?","fromName":"Jonathan del Strother","fromEmail":"maillist@steelskies.com","sentAt":"2007-12-22T15:48:21Z","receivedAt":"2007-12-22T15:48:21Z","isPatch":false,"sender":{"key":"jon.delstrother@bestbefore.tv","avatar":"https://gravatar.com/avatar/754e21ab701c00e2d21fc261187254c34b2a1c0b959d9ee5be1a295990be3081?d=mp&s=160"},"body":"On Dec 22, 2007 8:39 AM, Junio C Hamano wrote:\n> On Dec 19, 2007 6:44 PM, Alex Riesen wrote:\n> > Could you try\n> >\n> > git cat-file 18d2480ab689b483ef1ebbdb3f7420904049ba0b\n> >\n> > (or any other problematic commit) and post its output here?\n>\n> You mean git cat-file commit ... ?\n> I get the normal output, but the problematic commits don't show a\n> newline character at the end of the cat-file output.\n>\n> \"I get the normal output\" is not what Alex asked you to supply,\n> nor would be sufficient information. There may be some\n> abnormality in the commit object that you probably did not spot,\n> but Alex or other people may have been able to if you were\n> actually posted its output here.\n========\n$ git cat-file commit 18d2480ab689b483ef1ebbdb3f7420904049ba0b\ntree 2416c620c6f7c1864065a6e778588b71b3e0bd5d\nparent 9fc80d0a05835c68885f253844ab586b38d09202\nauthor Jonathan del Strother 1197907511 +0000\ncommitter Jonathan del Strother 1197907511 +0000\n\nTry to flush log files before terminating the app%\n========\nThe '%' suffix is zsh showing that there's no newline there. Under\nbash I get no '%' and the next prompt starts immediately following\n'app'.\n\n> One thing I noticed funny in your original message was \"-1-\".\n> Is it essential that the number is spelled incorrectly to\n> reproduce this problem?\n\nNo, sorry - I don't know how that got there. I get identical output\nwhether it's \"rev-list -1\" or \"rev-list -1-\"\n\n\n\nI've been trying to reproduce this on my home repo, and have only been\npartially successful. I haven't been able to make git rev-list -1\nshow a malformed message body. I can only get the problem to occur\nwhen printing multiple commits (eg git rev-list -20 ...) Bizarrely,\nthe first 2 commits shown in rev-list never show a problem. After the\nfirst 2, commits with the broken message bodies will always appear\nbroken, regardless of their position in the list. However, the\ncontent that appears instead of the body will change depending on the\ncommits that appear prior to that one.\n\nI realise this doesn't appear to mesh with my observations the other\nday, where I was seeing the broken bodies even when just using\nrev-list -1 - I'm at a loss to describe it. Both machines are intel\nmacs (one a MacPro, one a MacBook Pro), running OS X 10.5.1, with the\nsame git version (1.5.4.rc0.1162.g3bfea). Unfortunately I've switched\nmy work machine off for christmas, or I'd ssh in and try to re-verify\nthings.\n\n\nI do appreciate people's help in trying to reproduce & fix this - I\nrealise I've not given people much to go on.\n"}]}