{"thread":{"id":"9201","subject":"rfe: bisecting with a tristate","startedAt":"2007-07-24T13:21:19Z","lastAt":"2007-07-24T21:39:06Z","messageCount":6,"participants":["Jan Engelhardt","Sean","Johannes Schindelin","Robin Rosenberg"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"48456","messageId":"Pine.LNX.4.64.0707241459460.18990@fbirervta.pbzchgretzou.qr","threadId":"9201","inReplyTo":null,"subject":"rfe: bisecting with a tristate","fromName":"Jan Engelhardt","fromEmail":"jengelh@computergmbh.de","sentAt":"2007-07-24T13:21:19Z","receivedAt":"2007-07-24T13:21:19Z","isPatch":false,"sender":{"key":"jengelh@computergmbh.de","avatar":null},"body":"Hi,\n\n\nI have an idea about handling commits that do not compile at \nall in git-bisect.\nFor example:\n\ngit bisect start\ngit bisect bad v2.6.23-rc1\n# bad: [f695baf2df9e0413d3521661070103711545207a] Linux 2.6.23-rc1\ngit bisect good v2.6.22\n# good: [098fd16f00005f665d3baa7e682d8cb3d7c0fe6f] Linux 2.6.22\n\nThen 1f1c2881f673671539b25686df463518d69c4649 will be the next commit \ngit bisect hands out. Now let's assume this commit would not compile. \nWhat would the user do? git-bisect good or git-bisect bad?\n\nAssume a commit previous to 1f..49 caused an oops (but the user does not \nknow yet), and the user said 'good' on 1f..49 because he did not know \nwhat to say (since it did not compile). Then bisect would go the wrong \nway, marking all left to 1f..49 as good.\n\n\nIdeally, there should be like \"git bisect dunno-try-left\" and \"git \nbisect dunno-try-right\", which allow the user to skip checking 1f..49 \nand instead try the next commit left or right of 1f..49 (to either go to \na commit before the compile failure, or after it).\n\n[ What's `git-bisect next` for? ]\n\n\n\n\tJan\n-- \n"},{"id":"48462","messageId":"20070724094017.d14688e5.seanlkml@sympatico.ca","threadId":"9201","inReplyTo":"Pine.LNX.4.64.0707241459460.18990@fbirervta.pbzchgretzou.qr","subject":"Re: rfe: bisecting with a tristate","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2007-07-24T13:40:17Z","receivedAt":"2007-07-24T13:40:17Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 24 Jul 2007 15:21:19 +0200 (CEST)\nJan Engelhardt <jengelh@computergmbh.de> wrote:\n\n\nHi Jan,\n\n> I have an idea about handling commits that do not compile at \n> all in git-bisect.\n> For example:\n> \n> git bisect start\n> git bisect bad v2.6.23-rc1\n> # bad: [f695baf2df9e0413d3521661070103711545207a] Linux 2.6.23-rc1\n> git bisect good v2.6.22\n> # good: [098fd16f00005f665d3baa7e682d8cb3d7c0fe6f] Linux 2.6.22\n> \n> Then 1f1c2881f673671539b25686df463518d69c4649 will be the next commit \n> git bisect hands out. Now let's assume this commit would not compile. \n> What would the user do? git-bisect good or git-bisect bad?\n\nCheck out the section \"Avoiding to test a commit\" in the git-bisect\nman page; it addresses this issue.  Basically you just use git-reset\nto pick a different nearby commit to compile, and then continue with\ngit bisect good/bad.\n\n> \n> Assume a commit previous to 1f..49 caused an oops (but the user does not \n> know yet), and the user said 'good' on 1f..49 because he did not know \n> what to say (since it did not compile). Then bisect would go the wrong \n> way, marking all left to 1f..49 as good.\n> \n> Ideally, there should be like \"git bisect dunno-try-left\" and \"git \n> bisect dunno-try-right\", which allow the user to skip checking 1f..49 \n> and instead try the next commit left or right of 1f..49 (to either go to \n> a commit before the compile failure, or after it).\n>\n\nSean\n"},{"id":"48467","messageId":"Pine.LNX.4.64.0707241447200.14781@racer.site","threadId":"9201","inReplyTo":"20070724094017.d14688e5.seanlkml@sympatico.ca","subject":"Re: rfe: bisecting with a tristate","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-24T13:52:40Z","receivedAt":"2007-07-24T13:52:40Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 24 Jul 2007, Sean wrote:\n\n> > git bisect start\n> > git bisect bad v2.6.23-rc1\n> > # bad: [f695baf2df9e0413d3521661070103711545207a] Linux 2.6.23-rc1\n> > git bisect good v2.6.22\n> > # good: [098fd16f00005f665d3baa7e682d8cb3d7c0fe6f] Linux 2.6.22\n> > \n> > Then 1f1c2881f673671539b25686df463518d69c4649 will be the next commit \n> > git bisect hands out. Now let's assume this commit would not compile. \n> > What would the user do? git-bisect good or git-bisect bad?\n> \n> Check out the section \"Avoiding to test a commit\" in the git-bisect\n> man page; it addresses this issue.  Basically you just use git-reset\n> to pick a different nearby commit to compile, and then continue with\n> git bisect good/bad.\n\nBut a \"git bisect dunno\" would be handy.\n\nHowever, it is a bit involved, since git-bisect.sh assumes that there is \nonly one bad commit, and with that, the outcome would be possibly a commit \nrange.\n\nTwo parts to it I see:\n\n- builtin-rev-list.c:find_bisection() has to be told to ignore the dunno \n  commits when counting, in addition to uninteresting ones (but not stop \n  traversal). The easiest way I could see would be to add another option \n  to specify the dunno commits, and set a special flag on these.\n\n- git-bisect.sh has to lose the assumption that there is only one bad \n  commit.  Instead, it has to traverse the parent(s) of \"the\" bad commit, \n  until it finds either no parents, or a known good one.  So maybe \n  something like\n\n\techo $(git rev-list --boundary $bad --not $good |\n\t\tsed -n \"s/^-/^/p\") $bad\n\n  would be enough.\n\nHth,\nDscho\n"},{"id":"48486","messageId":"200707241907.57857.robin.rosenberg.lists@dewire.com","threadId":"9201","inReplyTo":"Pine.LNX.4.64.0707241447200.14781@racer.site","subject":"Re: rfe: bisecting with a tristate","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2007-07-24T17:07:56Z","receivedAt":"2007-07-24T17:07:56Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"tisdag 24 juli 2007 skrev Johannes Schindelin:\n> Hi,\n> \n> On Tue, 24 Jul 2007, Sean wrote:\n> \n> > > git bisect start\n> > > git bisect bad v2.6.23-rc1\n> > > # bad: [f695baf2df9e0413d3521661070103711545207a] Linux 2.6.23-rc1\n> > > git bisect good v2.6.22\n> > > # good: [098fd16f00005f665d3baa7e682d8cb3d7c0fe6f] Linux 2.6.22\n> > > \n> > > Then 1f1c2881f673671539b25686df463518d69c4649 will be the next commit \n> > > git bisect hands out. Now let's assume this commit would not compile. \n> > > What would the user do? git-bisect good or git-bisect bad?\n> > \n> > Check out the section \"Avoiding to test a commit\" in the git-bisect\n> > man page; it addresses this issue.  Basically you just use git-reset\n> > to pick a different nearby commit to compile, and then continue with\n> > git bisect good/bad.\n> \n> But a \"git bisect dunno\" would be handy.\n\nWhy? Not doing anything is enough, just select a new commit. Going back can be done by\ngit reset, but forward (towards original HEAD) requires more thinking so a git bisect forward [n]\nwould help there.\n\n-- robin\n"},{"id":"48487","messageId":"Pine.LNX.4.64.0707241818450.14781@racer.site","threadId":"9201","inReplyTo":"200707241907.57857.robin.rosenberg.lists@dewire.com","subject":"Re: rfe: bisecting with a tristate","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-24T17:21:33Z","receivedAt":"2007-07-24T17:21:33Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 24 Jul 2007, Robin Rosenberg wrote:\n\n> tisdag 24 juli 2007 skrev Johannes Schindelin:\n> \n> > On Tue, 24 Jul 2007, Sean wrote:\n> > \n> > > > git bisect start\n> > > > git bisect bad v2.6.23-rc1\n> > > > # bad: [f695baf2df9e0413d3521661070103711545207a] Linux 2.6.23-rc1\n> > > > git bisect good v2.6.22\n> > > > # good: [098fd16f00005f665d3baa7e682d8cb3d7c0fe6f] Linux 2.6.22\n> > > > \n> > > > Then 1f1c2881f673671539b25686df463518d69c4649 will be the next commit \n> > > > git bisect hands out. Now let's assume this commit would not compile. \n> > > > What would the user do? git-bisect good or git-bisect bad?\n> > > \n> > > Check out the section \"Avoiding to test a commit\" in the git-bisect\n> > > man page; it addresses this issue.  Basically you just use git-reset\n> > > to pick a different nearby commit to compile, and then continue with\n> > > git bisect good/bad.\n> > \n> > But a \"git bisect dunno\" would be handy.\n> \n> Why? Not doing anything is enough, just select a new commit. Going back \n> can be done by git reset, but forward (towards original HEAD) requires \n> more thinking so a git bisect forward [n] would help there.\n\nAnd why exactly do you want to make it hard on the user?\n\nImagine this history:\n\n\tA - B - broken - bad - C\n\nNow you bisect.  It goes to \"broken\".  You compile.  Darn, does not \ncompile.  Why not have a \"git bisect dunno\", which considers only the \n_rest_ of the commits for the next bisection point?  When it finally found \nthe \"bad\" one, it has to say it broke somewhere between \"B..bad\".\n\nNow that would be user friendly, wouldn't it?\n\nCiao,\nDscho\n"},{"id":"48521","messageId":"200707242339.07980.robin.rosenberg.lists@dewire.com","threadId":"9201","inReplyTo":"Pine.LNX.4.64.0707241818450.14781@racer.site","subject":"Re: rfe: bisecting with a tristate","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2007-07-24T21:39:06Z","receivedAt":"2007-07-24T21:39:06Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"tisdag 24 juli 2007 skrev Johannes Schindelin:\n> And why exactly do you want to make it hard on the user?\n\nNah, I don't want to do that. Just thinking aloud ;-)\n \n> Imagine this history:\n> \n> \tA - B - broken - bad - C\n> \n> Now you bisect.  It goes to \"broken\".  You compile.  Darn, does not \n> compile.  Why not have a \"git bisect dunno\", which considers only the \n> _rest_ of the commits for the next bisection point?  When it finally found \n> the \"bad\" one, it has to say it broke somewhere between \"B..bad\".\n> \n> Now that would be user friendly, wouldn't it?\n\nIt would work fine.\n\n-- robin\n"}]}