{"thread":{"id":"47254","subject":"t3512 & t3513 'unexpected passes'","startedAt":"2017-11-20T20:16:57Z","lastAt":"2017-11-22T01:41:05Z","messageCount":4,"participants":["Ramsay Jones","Adam Dinwoodie","Phillip Wood","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"332934","messageId":"73f0fb1e-5b55-1049-7706-652f1f9deaed@ramsayjones.plus.com","threadId":"47254","inReplyTo":null,"subject":"t3512 & t3513 'unexpected passes'","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2017-11-20T20:16:49Z","receivedAt":"2017-11-20T20:16:57Z","isPatch":false,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"Hi Junio,\n\nFor several days, I have been staring at some 'unexpected passes' in\nthe t3512-cherry-pick-submodule.sh and t3513-revert-submodule.sh test\nfiles (tests #11-13 in both cases).\n\nI finally found time tonight to 'git bisect' the 'problem', and found\nthat bisect fingered commit b5a812b298 (\"sequencer: try to commit without\n forking 'git commit'\", 17-11-2017).\n\nDuring the bisection I stumbled across (several times) the following\ncompilation error:\n\n CC sequencer.o\n sequencer.c: In function ‘do_commit’:\n sequencer.c:1142:9: error: void value not ignored as it ought to be\n res = print_commit_summary(NULL, &oid,\n ^\n Makefile:2105: recipe for target 'sequencer.o' failed\n make: *** [sequencer.o] Error 1\n\nwhich I 'fixed' like so: s/res = //\n\nSo, given that the 'fingered' commit didn't immediately seem to be\nrelated to the problem, along with the above errors, this may well\nnot be the culprit.\n\nJust FYI.\n\nATB,\nRamsay Jones\n\n"},{"id":"333087","messageId":"20171121104404.GN20681@dinwoodie.org","threadId":"47254","inReplyTo":"73f0fb1e-5b55-1049-7706-652f1f9deaed@ramsayjones.plus.com","subject":"Re: t3512 & t3513 'unexpected passes'","fromName":"Adam Dinwoodie","fromEmail":"adam@dinwoodie.org","sentAt":"2017-11-21T10:44:04Z","receivedAt":"2017-11-21T10:44:30Z","isPatch":false,"sender":{"key":"adam@dinwoodie.org","avatar":"https://avatars.githubusercontent.com/u/1397507?v=4"},"body":"On Monday 20 November 2017 at 08:16 pm +0000, Ramsay Jones wrote:\n> For several days, I have been staring at some 'unexpected passes' in\n> the t3512-cherry-pick-submodule.sh and t3513-revert-submodule.sh test\n> files (tests #11-13 in both cases).\n> \n> I finally found time tonight to 'git bisect' the 'problem', and found\n> that bisect fingered commit b5a812b298 (\"sequencer: try to commit without\n> forking 'git commit'\", 17-11-2017).\n> \n> During the bisection I stumbled across (several times) the following\n> compilation error:\n> \n> CC sequencer.o\n> sequencer.c: In function ‘do_commit’:\n> sequencer.c:1142:9: error: void value not ignored as it ought to be\n> res = print_commit_summary(NULL, &oid,\n> ^\n> Makefile:2105: recipe for target 'sequencer.o' failed\n> make: *** [sequencer.o] Error 1\n> \n> which I 'fixed' like so: s/res = //\n> \n> So, given that the 'fingered' commit didn't immediately seem to be\n> related to the problem, along with the above errors, this may well\n> not be the culprit.\n\nI've seen the same unexpected passes, and had just completed the same\nbisect run myself, although I fixed the build failure by cherry-picking\n82921316a (\"SQUASH???\", 2017-11-18) onto commits that wouldn't build,\ngiven that commit seems to exist entirely to fix that build breakage. I\nthink that adds more weight to b5a812b29 being the culprit for these\nunexpected passes.\n\nIt's definitely the case that these unexpected passes exist at 8e4ff0ae1\n(\"Merge branch 'pw/sequencer-in-process-commit' into pu\", 2017-11-21)\nand do not exist at its immediate left-hand parent, e017a4ccc (\"Merge\nbranch 'jn/ssh-wrappers' into jch\", 2017-11-21), which means it's\nclearly _something_ in the branch merged at 8e4ff0ae1.\n"},{"id":"333113","messageId":"a3ed15c4-61b7-aae2-d849-4dbea2fd7511@talktalk.net","threadId":"47254","inReplyTo":"20171121104404.GN20681@dinwoodie.org","subject":"Re: t3512 & t3513 'unexpected passes'","fromName":"Phillip Wood","fromEmail":"phillip.wood@talktalk.net","sentAt":"2017-11-21T18:19:06Z","receivedAt":"2017-11-21T18:19:16Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"On 21/11/17 10:44, Adam Dinwoodie wrote:\n> On Monday 20 November 2017 at 08:16 pm +0000, Ramsay Jones wrote:\n>> For several days, I have been staring at some 'unexpected passes' in\n>> the t3512-cherry-pick-submodule.sh and t3513-revert-submodule.sh test\n>> files (tests #11-13 in both cases).\n\nThanks for pointing this out.\n\n\n\n> I've seen the same unexpected passes, and had just completed the same\n> bisect run myself, although I fixed the build failure by cherry-picking\n> 82921316a (\"SQUASH???\", 2017-11-18) onto commits that wouldn't build,\n> given that commit seems to exist entirely to fix that build breakage. I\n> think that adds more weight to b5a812b29 being the culprit for these\n> unexpected passes.\n> \n> It's definitely the case that these unexpected passes exist at 8e4ff0ae1\n> (\"Merge branch 'pw/sequencer-in-process-commit' into pu\", 2017-11-21)\n> and do not exist at its immediate left-hand parent, e017a4ccc (\"Merge\n> branch 'jn/ssh-wrappers' into jch\", 2017-11-21), which means it's\n> clearly _something_ in the branch merged at 8e4ff0ae1.\n\nIf I've understood the comments by those tests this has to do with the\nnew code detecting empty commits where the old code does not or vice\nversa. The new code detects an attempt to create an empty commit by\ncomparing the tree that is about to be committed to HEAD and complains\nif they are the same. I've had a quick look through the code for 'git\ncommit' but I need more time to figure out exactly what it does in this\ncase (I've a feeling from when I looked a while ago that it does this\ntest before it writes the tree). If anyone has any insight as to why the\ntests fail with the current commit implementation that would be helpful\nfor understanding what is going on here - unfortunately I've never\nreally used submodules.\n\nBest Wishes\n\nPhillip\n\n\n"},{"id":"333214","messageId":"xmqq1skrytsl.fsf@gitster.mtv.corp.google.com","threadId":"47254","inReplyTo":"20171121104404.GN20681@dinwoodie.org","subject":"Re: t3512 & t3513 'unexpected passes'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-11-22T01:40:58Z","receivedAt":"2017-11-22T01:41:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Adam Dinwoodie writes:\n\n> I've seen the same unexpected passes, and had just completed the same\n> bisect run myself, although I fixed the build failure by cherry-picking\n> 82921316a (\"SQUASH???\", 2017-11-18) onto commits that wouldn't build,\n> given that commit seems to exist entirely to fix that build breakage.\n\nYour assumption is correct wrt \"SQUASH???\". When I am in a hurry\nand cannot spend extra cycles to pinpoint which one of the commits\nin a multi-patch series breaks a build, I just fix the breakage on\ntop of the tip commit, and leave it to the original author of the\nseries to apply them down to the original breakage in individual\ncommits when the topic is rerolled.\n\nIt seems that the compilation breakage 82921316a fixes comes from\nits immediate parent, so I'll squash them together, just in case a\nrerolled topic does not materialize.\n\nThanks.\n\n"}]}