{"thread":{"id":"2717","subject":"git bisect enhancements?","startedAt":"2005-11-30T21:36:26Z","lastAt":"2005-11-30T23:32:20Z","messageCount":6,"participants":["Jon Loeliger","Junio C Hamano","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"13006","messageId":"1133386585.30767.34.camel@cashmere.sps.mot.com","threadId":"2717","inReplyTo":null,"subject":"git bisect enhancements?","fromName":"Jon Loeliger","fromEmail":"jdl@freescale.com","sentAt":"2005-11-30T21:36:26Z","receivedAt":"2005-11-30T21:36:26Z","isPatch":false,"sender":{"key":"jdl@jdl.com","avatar":"https://gravatar.com/avatar/75ce9a10b151acd2c28ec4ab2136dba7b2ff1634530bd04b155981a749d08a64?d=mp&s=160"},"body":"Guys,\n\nSo, I'm in the middle of a Git Bisect War.\nIt all worked around 2.6.13-rc3 time, and doesn't now.\n\nSo I launched into some bisecting, and it is all going\npretty smoothly so far. But I think there is an obvious\nenhancement that I would like to propose for discussion.\n\nFirst, the problem I'm seeing is that the current top\nof tree hangs an mpc8555_cds_defconfig build. Bummer.\nDoesn't get past the traditional \"uncompressing image...\"\nmessage.\n\nTwo or three \"good builds\" into things, it proposes a\nnew build at a272e24cc8751d125f9582befed0213a2a2b270f.\nWhich I build and don't quite boot. It hangs after\nthe IDE probe, and before the i2c probe. Bummer.\n\nThese are not bugs I was looking for. Move along.\n\nSo I lie and claim \"git bisect good\", making a *scratch* note\nof where the \"git bisect log\" seems to think I am so that\nI might come back here and claim \"git bisect bad\" later.\n\nThe _next_ proposed split is at\na272e24cc8751d125f9582befed0213a2a2b270f\nwhere I can clearly see using \"git bisect visualize\" that\na much better, perhaps more quiescent choice is two commits\nlater. The proposed bisect location is in the middle of\na series of commits from paulus tinkering with the PPC\nmerge tree. Two commits later, though, Linus has merged\nit in totally. It will be less \"in the middle\" of things\nand more quiescent. I want to \"bump\" the bisect point\nup two commits and _then_ build.\n\nSo, I'm proposing something like:\n\n $ git bisect bump +\n $ git bisect bump -\n\nTo move the bisection point \"up\" or \"down\" a commit chain.\n\nAm I off in the weeds?\n\nThanks,\njdl\n"},{"id":"13009","messageId":"7vu0dtokqp.fsf@assigned-by-dhcp.cox.net","threadId":"2717","inReplyTo":"1133386585.30767.34.camel@cashmere.sps.mot.com","subject":"Re: git bisect enhancements?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-30T22:04:46Z","receivedAt":"2005-11-30T22:04:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jon Loeliger writes:\n\n> ... I want to \"bump\" the bisect point\n> up two commits and _then_ build.\n>\n> So, I'm proposing something like:\n>\n> $ git bisect bump +\n> $ git bisect bump -\n>\n> To move the bisection point \"up\" or \"down\" a commit chain.\n\nHmph. Doesn't \"bisect good\" or \"bisect bad\" let you explicitly\nsay which one is good or bad, instead of just taking what it\nsuggests as the next midpoint?\n"},{"id":"13010","messageId":"1133388429.30767.37.camel@cashmere.sps.mot.com","threadId":"2717","inReplyTo":"7vu0dtokqp.fsf@assigned-by-dhcp.cox.net","subject":"Re: git bisect enhancements?","fromName":"Jon Loeliger","fromEmail":"jdl@freescale.com","sentAt":"2005-11-30T22:07:09Z","receivedAt":"2005-11-30T22:07:09Z","isPatch":false,"sender":{"key":"jdl@jdl.com","avatar":"https://gravatar.com/avatar/75ce9a10b151acd2c28ec4ab2136dba7b2ff1634530bd04b155981a749d08a64?d=mp&s=160"},"body":"On Wed, 2005-11-30 at 16:04, Junio C Hamano wrote:\n> Jon Loeliger writes:\n> \n> > ... I want to \"bump\" the bisect point\n> > up two commits and _then_ build.\n> >\n> > So, I'm proposing something like:\n> >\n> > $ git bisect bump +\n> > $ git bisect bump -\n> >\n> > To move the bisection point \"up\" or \"down\" a commit chain.\n> \n> Hmph. Doesn't \"bisect good\" or \"bisect bad\" let you explicitly\n> say which one is good or bad, instead of just taking what it\n> suggests as the next midpoint?\n\nSure. But I'm proposing to alter the new bisection\nmiddle point. I don't know its status yet. I am\njust angling on hedging my bets of a \"good midpoint\"\nchoice by finding something that is likely to be\nmore stable than the proposed midpoint.\n\njdl\n"},{"id":"13012","messageId":"7vmzjlojw6.fsf@assigned-by-dhcp.cox.net","threadId":"2717","inReplyTo":"1133388429.30767.37.camel@cashmere.sps.mot.com","subject":"Re: git bisect enhancements?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-30T22:23:05Z","receivedAt":"2005-11-30T22:23:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jon Loeliger writes:\n\n> Sure. But I'm proposing to alter the new bisection\n> middle point. I don't know its status yet. I am\n> just angling on hedging my bets of a \"good midpoint\"\n> choice by finding something that is likely to be\n> more stable than the proposed midpoint.\n\nYou could \"git reset --hard \",\ncompile, test and say \"git bisect good\" or \"git bisect bad\".\n\nEven \"N commits before\" is not so easy. \"git reset --hard\nbisect~2\" would be 2 commits before what git-bisect suggested as\nlong as that chain in question is a single strand of pearls. \"N\ncommits after\" is a bit harder, especially when a merge is\ninvolved. But you are right. Bisect should be able to do what\nyou can visually do with gitk.\n"},{"id":"13016","messageId":"7v3bldoiyq.fsf@assigned-by-dhcp.cox.net","threadId":"2717","inReplyTo":"1133386585.30767.34.camel@cashmere.sps.mot.com","subject":"Re: git bisect enhancements?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-30T22:43:09Z","receivedAt":"2005-11-30T22:43:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jon Loeliger writes:\n\n>...\n> Two or three \"good builds\" into things, it proposes a\n> new build at a272e24cc8751d125f9582befed0213a2a2b270f.\n> Which I build and don't quite boot. It hangs after\n> the IDE probe, and before the i2c probe. Bummer.\n>\n> These are not bugs I was looking for. Move along.\n\nThis is not about your \"bump\", but one thing that may worthwhile\nto try is bisect enhancements Linus did a couple of days ago, to\nlet you limit the number of commits tried by specifying the area\nyou are interested in.\n\nIf may not help if only thing you know is that i2c probe is not\nwhat you are looking for, but if you know what area is suspect,\nsay arch/powerpc and include/asm-powerpc (just taken randomly, I\ndo not even know if you work in that area), it lets you say:\n\n\t$ git bisect reset\n\t$ git bisect start arch/powerpc include/asm-powerpc\n $ git bisect good v2.6.13-rc3\n $ git bisect bad master\n\nWhat is interesting is that this cuts down the commits to be\ninspected to only the ones that touch the specified paths. So\nwithout the path specifier, you may need to bisect 5000 commits in\ntotal, but with the commits limited to the ones that touch these\ntwo example directories, you would need to bisect 247 commits,\nwhich is only a fraction of the original.\n"},{"id":"13020","messageId":"Pine.LNX.4.64.0511301526530.3099@g5.osdl.org","threadId":"2717","inReplyTo":"1133386585.30767.34.camel@cashmere.sps.mot.com","subject":"Re: git bisect enhancements?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-11-30T23:32:20Z","receivedAt":"2005-11-30T23:32:20Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 30 Nov 2005, Jon Loeliger wrote:\n> \n> So, I'm proposing something like:\n> \n> $ git bisect bump +\n> $ git bisect bump -\n> \n> To move the bisection point \"up\" or \"down\" a commit chain.\n> \n> Am I off in the weeds?\n\nNo, but we already have it.\n\nIf you decide to select a new bisection point by hand, just do it. It's \ncalled\n\n\tgit reset --hard \n\nand it will simply move the bisect branch to the new point.\n\nThen, compile and test that, and use \"git bisect good/bad\" as necessary.\n\nNow, I agree that maybe I could have made that a bit more obvious, but it \nshould all work.\n\nSame goes for the case where \"git bisect\" selects a point that happens to \nhave a different problem than the one you were looking for. Instead of \nsaying \"git bisect good\" (or bad) and praying you got it right, just do \nthat \"git bisect visualize\" and select another point entirely, and do that \nsame \"git reset --hard\" thing, and leave the one you don't know about \nalone.\n\nOf course, if you make a bad selection, you might have that problem again, \nor more commonly, you'll just have to test more kernels because your \nselection wasn't as close to \"midway\" as the one \"git bisect\" had selected \nfor you. But you'll get there eventually.\n\n[ Now, the _real_ problem with bisection is that some bugs simply cannot \n be bisected. If it's timing-related etc, it might be a bug that comes \n and goes, and then I'm afraid that git bisect won't really help you. ]\n\n\t\t\tLinus\n"}]}