{"thread":{"id":"20185","subject":"[RFE] allow git bisect to figure out in which revision a bug was fixed","startedAt":"2009-07-21T20:16:50Z","lastAt":"2009-07-22T02:41:17Z","messageCount":10,"participants":["Jeff Moyer","Junio C Hamano","Josef Bacik","Nicolas Pitre"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"118402","messageId":"x49ocrdokp9.fsf@segfault.boston.devel.redhat.com","threadId":"20185","inReplyTo":null,"subject":"[RFE] allow git bisect to figure out in which revision a bug was fixed","fromName":"Jeff Moyer","fromEmail":"jmoyer@redhat.com","sentAt":"2009-07-21T20:16:50Z","receivedAt":"2009-07-21T20:16:50Z","isPatch":false,"sender":{"key":"jmoyer@redhat.com","avatar":"https://gravatar.com/avatar/4a086408b000579d3a97c0315a2e7c941f7793220dab3d23bf1be3cf741f0ed8?d=mp&s=160"},"body":"Hi,\n\nAs a distro kernel grunt, I sometimes find myself in the situation of\nhaving to track down the commit that fixed a given problem so that I can\nbackport it to an older kernel. Sometimes I'm smart enough to figure it\nout myself, other times I'm not. ;-) It would be helpful if git bisect\ncould help figure out in what commit a bug was fixed as opposed to\nintroduced. Is there any interest in implementing such a feature?\n\nThanks,\nJeff\n"},{"id":"118417","messageId":"7vfxcpdbsh.fsf@alter.siamese.dyndns.org","threadId":"20185","inReplyTo":"x49ocrdokp9.fsf@segfault.boston.devel.redhat.com","subject":"Re: [RFE] allow git bisect to figure out in which revision a bug was fixed","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-07-21T20:24:46Z","receivedAt":"2009-07-21T20:24:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff Moyer writes:\n\n> As a distro kernel grunt, I sometimes find myself in the situation of\n> having to track down the commit that fixed a given problem so that I can\n> backport it to an older kernel. Sometimes I'm smart enough to figure it\n> out myself, other times I'm not. ;-) It would be helpful if git bisect\n> could help figure out in what commit a bug was fixed as opposed to\n> introduced. Is there any interest in implementing such a feature?\n\nDoesn't that already exist?\n\nYou are hunting for an existence of the bug, so any commit that is buggy\n(with respect to the bug you are interested in) is *GOOD*. The tip of the\nupstream is *BAD* in that it does not have your favourite bug anymore.\n\nYou bisect that history down, and will find the first *BAD* commit.\n\nNow, why is that commit the procedure finds is *BAD*, again? Yup, because\nit does not have your favourite bug anymore. And why is that so?\n\nBecause the commit fixed that bug.\n"},{"id":"118418","messageId":"20090721202848.GA3453@localhost.localdomain","threadId":"20185","inReplyTo":"7vfxcpdbsh.fsf@alter.siamese.dyndns.org","subject":"Re: [RFE] allow git bisect to figure out in which revision a bug was fixed","fromName":"Josef Bacik","fromEmail":"josef@redhat.com","sentAt":"2009-07-21T20:28:48Z","receivedAt":"2009-07-21T20:28:48Z","isPatch":false,"sender":{"key":"josef@redhat.com","avatar":null},"body":"On Tue, Jul 21, 2009 at 01:24:46PM -0700, Junio C Hamano wrote:\n> Jeff Moyer writes:\n> \n> > As a distro kernel grunt, I sometimes find myself in the situation of\n> > having to track down the commit that fixed a given problem so that I can\n> > backport it to an older kernel. Sometimes I'm smart enough to figure it\n> > out myself, other times I'm not. ;-) It would be helpful if git bisect\n> > could help figure out in what commit a bug was fixed as opposed to\n> > introduced. Is there any interest in implementing such a feature?\n> \n> Doesn't that already exist?\n> \n> You are hunting for an existence of the bug, so any commit that is buggy\n> (with respect to the bug you are interested in) is *GOOD*. The tip of the\n> upstream is *BAD* in that it does not have your favourite bug anymore.\n> \n> You bisect that history down, and will find the first *BAD* commit.\n> \n> Now, why is that commit the procedure finds is *BAD*, again? Yup, because\n> it does not have your favourite bug anymore. And why is that so?\n> \n> Because the commit fixed that bug.\n\nSure, but as one who has used this procedure several times before, it is very\nerror prone, on my side because I'm a big goober. I have a tendancy to get my\nwires crossed and get dumped out at a commit that doesnt make sense (my latest\nattempt put me out at a merge commit). Sure its my fault for not being able to\nkeep it straight, theres no arguing that, it still would be nice for there to be\na way to remove as much human error from the process as possible. Thanks,\n\nJosef\n"},{"id":"118421","messageId":"x49k521ojv1.fsf@segfault.boston.devel.redhat.com","threadId":"20185","inReplyTo":"20090721202848.GA3453@localhost.localdomain","subject":"Re: [RFE] allow git bisect to figure out in which revision a bug was fixed","fromName":"Jeff Moyer","fromEmail":"jmoyer@redhat.com","sentAt":"2009-07-21T20:34:58Z","receivedAt":"2009-07-21T20:34:58Z","isPatch":false,"sender":{"key":"jmoyer@redhat.com","avatar":"https://gravatar.com/avatar/4a086408b000579d3a97c0315a2e7c941f7793220dab3d23bf1be3cf741f0ed8?d=mp&s=160"},"body":"Josef Bacik writes:\n\n> On Tue, Jul 21, 2009 at 01:24:46PM -0700, Junio C Hamano wrote:\n>> Jeff Moyer writes:\n>> \n>> > As a distro kernel grunt, I sometimes find myself in the situation of\n>> > having to track down the commit that fixed a given problem so that I can\n>> > backport it to an older kernel. Sometimes I'm smart enough to figure it\n>> > out myself, other times I'm not. ;-) It would be helpful if git bisect\n>> > could help figure out in what commit a bug was fixed as opposed to\n>> > introduced. Is there any interest in implementing such a feature?\n>> \n>> Doesn't that already exist?\n>> \n>> You are hunting for an existence of the bug, so any commit that is buggy\n>> (with respect to the bug you are interested in) is *GOOD*. The tip of the\n>> upstream is *BAD* in that it does not have your favourite bug anymore.\n>> \n>> You bisect that history down, and will find the first *BAD* commit.\n>> \n>> Now, why is that commit the procedure finds is *BAD*, again? Yup, because\n>> it does not have your favourite bug anymore. And why is that so?\n>> \n>> Because the commit fixed that bug.\n>\n> Sure, but as one who has used this procedure several times before, it is very\n> error prone, on my side because I'm a big goober. I have a tendancy to get my\n> wires crossed and get dumped out at a commit that doesnt make sense (my latest\n> attempt put me out at a merge commit). Sure its my fault for not being able to\n> keep it straight, theres no arguing that, it still would be nice for there to be\n> a way to remove as much human error from the process as possible. Thanks,\n\nAnd now that I've done the research I should have done before posting, I\nsee that this feature has been requested at least 2 other times. I can\nget by the way things stand, for sure, but it sounds like there's\ninterest in making things a bit more user friendly.\n\nThanks for your time.\n\n-Jeff\n"},{"id":"118422","messageId":"7vprbtbwhu.fsf@alter.siamese.dyndns.org","threadId":"20185","inReplyTo":"20090721202848.GA3453@localhost.localdomain","subject":"Re: [RFE] allow git bisect to figure out in which revision a bug was fixed","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-07-21T20:40:29Z","receivedAt":"2009-07-21T20:40:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Josef Bacik writes:\n\n> On Tue, Jul 21, 2009 at 01:24:46PM -0700, Junio C Hamano wrote:\n>> Jeff Moyer writes:\n>> \n>> > As a distro kernel grunt, I sometimes find myself in the situation of\n>> > having to track down the commit that fixed a given problem so that I can\n>> > backport it to an older kernel. Sometimes I'm smart enough to figure it\n>> > out myself, other times I'm not. ;-) It would be helpful if git bisect\n>> > could help figure out in what commit a bug was fixed as opposed to\n>> > introduced. Is there any interest in implementing such a feature?\n>> \n>> Doesn't that already exist?\n>> \n>> You are hunting for an existence of the bug, so any commit that is buggy\n>> (with respect to the bug you are interested in) is *GOOD*. The tip of the\n>> upstream is *BAD* in that it does not have your favourite bug anymore.\n>> \n>> You bisect that history down, and will find the first *BAD* commit.\n>> \n>> Now, why is that commit the procedure finds is *BAD*, again? Yup, because\n>> it does not have your favourite bug anymore. And why is that so?\n>> \n>> Because the commit fixed that bug.\n>\n> Sure, but as one who has used this procedure several times before, it is\n> very error prone, on my side because I'm a big goober. I have a\n> tendancy to get my wires crossed and get dumped out at a commit that\n> doesnt make sense (my latest attempt put me out at a merge commit).\n> Sure its my fault for not being able to keep it straight, theres no\n> arguing that, it still would be nice for there to be a way to remove as\n> much human error from the process as possible. Thanks,\n\nThere indeed was discussions along the line of adding \"fixed\" and \"broken\"\nas synonyms to \"bad\" and \"good\".\n\nI mildly suspect that it is a matter of opinion if such an addition would\nmake things better or more confusing, because the word \"broken\" feels more\nstrongly associated with \"bad\" than \"good\".\n\nPerhaps \"wanted\" and \"unwanted\" makes a better pair of more neutral words?\nIn bisect, we do not want to judge commits' in absolute goodness scale.\nIt is all relative to what _you_ as the person who runs bisect want, and\nin that sense the original terminology \"good/bad\" was suboptimal.\n"},{"id":"118423","messageId":"x49fxcpoje1.fsf@segfault.boston.devel.redhat.com","threadId":"20185","inReplyTo":"7vprbtbwhu.fsf@alter.siamese.dyndns.org","subject":"Re: [RFE] allow git bisect to figure out in which revision a bug was fixed","fromName":"Jeff Moyer","fromEmail":"jmoyer@redhat.com","sentAt":"2009-07-21T20:45:10Z","receivedAt":"2009-07-21T20:45:10Z","isPatch":false,"sender":{"key":"jmoyer@redhat.com","avatar":"https://gravatar.com/avatar/4a086408b000579d3a97c0315a2e7c941f7793220dab3d23bf1be3cf741f0ed8?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> Josef Bacik writes:\n>\n>> On Tue, Jul 21, 2009 at 01:24:46PM -0700, Junio C Hamano wrote:\n>>> Jeff Moyer writes:\n>>> \n>>> > As a distro kernel grunt, I sometimes find myself in the situation of\n>>> > having to track down the commit that fixed a given problem so that I can\n>>> > backport it to an older kernel. Sometimes I'm smart enough to figure it\n>>> > out myself, other times I'm not. ;-) It would be helpful if git bisect\n>>> > could help figure out in what commit a bug was fixed as opposed to\n>>> > introduced. Is there any interest in implementing such a feature?\n>>> \n>>> Doesn't that already exist?\n>>> \n>>> You are hunting for an existence of the bug, so any commit that is buggy\n>>> (with respect to the bug you are interested in) is *GOOD*. The tip of the\n>>> upstream is *BAD* in that it does not have your favourite bug anymore.\n>>> \n>>> You bisect that history down, and will find the first *BAD* commit.\n>>> \n>>> Now, why is that commit the procedure finds is *BAD*, again? Yup, because\n>>> it does not have your favourite bug anymore. And why is that so?\n>>> \n>>> Because the commit fixed that bug.\n>>\n>> Sure, but as one who has used this procedure several times before, it is\n>> very error prone, on my side because I'm a big goober. I have a\n>> tendancy to get my wires crossed and get dumped out at a commit that\n>> doesnt make sense (my latest attempt put me out at a merge commit).\n>> Sure its my fault for not being able to keep it straight, theres no\n>> arguing that, it still would be nice for there to be a way to remove as\n>> much human error from the process as possible. Thanks,\n>\n> There indeed was discussions along the line of adding \"fixed\" and \"broken\"\n> as synonyms to \"bad\" and \"good\".\n>\n> I mildly suspect that it is a matter of opinion if such an addition would\n> make things better or more confusing, because the word \"broken\" feels more\n> strongly associated with \"bad\" than \"good\".\n>\n> Perhaps \"wanted\" and \"unwanted\" makes a better pair of more neutral words?\n> In bisect, we do not want to judge commits' in absolute goodness scale.\n> It is all relative to what _you_ as the person who runs bisect want, and\n> in that sense the original terminology \"good/bad\" was suboptimal.\n\nI think good and bad are fine. I like HPA's idea of just making a git\nbisect reverse.\n http://thread.gmane.org/gmane.comp.version-control.git/120013/focus=120107\n\nCheers,\nJeff\n"},{"id":"118436","messageId":"alpine.LFD.2.00.0907212030180.30629@xanadu.home","threadId":"20185","inReplyTo":"7vprbtbwhu.fsf@alter.siamese.dyndns.org","subject":"Re: [RFE] allow git bisect to figure out in which revision a bug was fixed","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2009-07-22T00:35:52Z","receivedAt":"2009-07-22T00:35:52Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 21 Jul 2009, Junio C Hamano wrote:\n\n> There indeed was discussions along the line of adding \"fixed\" and \"broken\"\n> as synonyms to \"bad\" and \"good\".\n> \n> I mildly suspect that it is a matter of opinion if such an addition would\n> make things better or more confusing, because the word \"broken\" feels more\n> strongly associated with \"bad\" than \"good\".\n> \n> Perhaps \"wanted\" and \"unwanted\" makes a better pair of more neutral words?\n> In bisect, we do not want to judge commits' in absolute goodness scale.\n> It is all relative to what _you_ as the person who runs bisect want, and\n> in that sense the original terminology \"good/bad\" was suboptimal.\n\nIt is short which is good.\n\nWhy not simply automatically inverting the meaning of good and\nbad based on which commit is the ancestor of the other initially?\n\n\nNicolas\n"},{"id":"118438","messageId":"7v4ot5zfqe.fsf@alter.siamese.dyndns.org","threadId":"20185","inReplyTo":"alpine.LFD.2.00.0907212030180.30629@xanadu.home","subject":"Re: [RFE] allow git bisect to figure out in which revision a bug was fixed","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-07-22T01:08:41Z","receivedAt":"2009-07-22T01:08:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> Why not simply automatically inverting the meaning of good and\n> bad based on which commit is the ancestor of the other initially?\n\nBecause neither may be an ancestor of the other?\n"},{"id":"118439","messageId":"alpine.LFD.2.00.0907212118550.30629@xanadu.home","threadId":"20185","inReplyTo":"7v4ot5zfqe.fsf@alter.siamese.dyndns.org","subject":"Re: [RFE] allow git bisect to figure out in which revision a bug was fixed","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2009-07-22T01:20:24Z","receivedAt":"2009-07-22T01:20:24Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 21 Jul 2009, Junio C Hamano wrote:\n\n> Nicolas Pitre writes:\n> \n> > Why not simply automatically inverting the meaning of good and\n> > bad based on which commit is the ancestor of the other initially?\n> \n> Because neither may be an ancestor of the other?\n\nIn most cases it has to be, no?\n\n\nNicolas\n"},{"id":"118443","messageId":"7vy6qhwib6.fsf@alter.siamese.dyndns.org","threadId":"20185","inReplyTo":"alpine.LFD.2.00.0907212118550.30629@xanadu.home","subject":"Re: [RFE] allow git bisect to figure out in which revision a bug was fixed","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-07-22T02:41:17Z","receivedAt":"2009-07-22T02:41:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> On Tue, 21 Jul 2009, Junio C Hamano wrote:\n>\n>> Nicolas Pitre writes:\n>> \n>> > Why not simply automatically inverting the meaning of good and\n>> > bad based on which commit is the ancestor of the other initially?\n>> \n>> Because neither may be an ancestor of the other?\n>\n> In most cases it has to be, no?\n\nNot necessarily.\n\nI think it depends on your workflow. When you bisect a topic branch that\nforked from 'master' some time ago, it is not unreasonable to start it\nwith\n\n\t$ git bisect start topic master\n\ninstead of\n\n\t$ git bisect start topic $(git merge-base master topic)\n\nRecent bisect would force you to check the merge base first as a sanity\ncheck, but I think you already need to have determined what good and bad\nmeans at that point if you take the route you suggested.\n"}]}