{"thread":{"id":"26287","subject":"git bisect problems/ideas","startedAt":"2011-01-15T07:33:12Z","lastAt":"2011-01-22T14:52:34Z","messageCount":17,"participants":["Aaron S. Meurer","Christian Couder","Jonathan Nieder","SZEDER Gábor","Junio C Hamano","Johannes Sixt","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"159525","messageId":"855249CA-A006-475C-8F96-EFD614795064@gmail.com","threadId":"26287","inReplyTo":null,"subject":"git bisect problems/ideas","fromName":"Aaron S. Meurer","fromEmail":"asmeurer@gmail.com","sentAt":"2011-01-15T07:33:12Z","receivedAt":"2011-01-15T07:33:12Z","isPatch":false,"sender":{"key":"asmeurer@gmail.com","avatar":"https://gravatar.com/avatar/d8229a7558fef02a1f7987c4a3d7aa29d8b14145b21481d6a23c0fb02e73d9e7?d=mp&s=160"},"body":"First off, do you guys have an issue tracker? I asked on IRC, and someone told me that he didn't think you did, and to just post here. After searching your websites, as far as I can tell he was right, though this is amazing to me that you can handle a project like this without an issue tracker. If you guys really do, then sorry. I would rather post this there than here (though if you really do, please make it more findable!)\n\nI just noticed this error/bug:\n\ngit checkout test\ngit bisect start \n\ngit branch -D test\n\ngit bisect reset\n\nAnd it gives an error, because test has been deleted. This is in 1.7.3.5. Now, I looked through the log of the current master of git to see if anything has been done about this, and all I noticed was the commit 3bb8cf88247db5, which essentially improves the error message. \n\nNow, this is good, because it seemed to me above that I was stuck bisecting until I recreated the test branch. I did not realize the git bisect syntax until later. \n\nBut this has brought me to bother you guys about something that has been bugging me for a while. I hate git bisect reset. 90% of the time I do not want to go back to where I started bisecting. I would much prefer to just have a git bisect stop command, which just stops the bisecting process, but leaves me where I am (like a shortcut to git bisect reset HEAD). This would be much more symmetric with git bisect start.\n\nWhile we are on the topic of bisecting, I have another issue. Can we remove the restriction that a \"bad\" commit come after a \"good\" commit? I'd say about 70% of the time I use bisect to find a commit that fixes a bug, not breaks it. Whenever this happens, I have to bend my mind over backwards to remind myself that the good behavior is really \"bad\" and the bad behavior is really \"good\". Is there a reason that git bisect can't just introspect from which comes earlier and which comes later to see which is \"good\" or \"bad\" (instead of just raising an error when they are in the \"wrong\" order)?\n\nAaron Meurer"},{"id":"159552","messageId":"AANLkTikNzpCwEieV8sXXctMm+DR69fkLfCF+F3xB6b-k@mail.gmail.com","threadId":"26287","inReplyTo":"855249CA-A006-475C-8F96-EFD614795064@gmail.com","subject":"Re: git bisect problems/ideas","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2011-01-17T09:38:05Z","receivedAt":"2011-01-17T09:38:05Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi,\n\nOn Sat, Jan 15, 2011 at 8:33 AM, Aaron S. Meurer wrote:\n> First off, do you guys have an issue tracker?\n\nNo, we don't. We use the mailing list.\n\n> I asked on IRC, and someone told me that he didn't think you did, and to just post here.  After searching your websites, as far as I can tell he was right, though this is amazing to me that you can handle a project like this without an issue tracker.  If you guys really do, then sorry.  I would rather post this there than here (though if you really do, please make it more findable!)\n>\n> I just noticed this error/bug:\n>\n> git checkout test\n> git bisect start\n> \n> git branch -D test\n> \n> git bisect reset\n>\n> And it gives an error, because test has been deleted.  This is in 1.7.3.5.  Now, I looked through the log of the current master of git to see if anything has been done about this, and all I noticed was the commit 3bb8cf88247db5, which essentially improves the error message.\n>\n> Now, this is good, because it seemed to me above that I was stuck bisecting until I recreated the test branch.  I did not realize the git bisect syntax until later.\n\nYou mean \"git bisect reset \".\n\n> But this has brought me to bother you guys about something that has been bugging me for a while. I hate git bisect reset.  90% of the time I do not want to go back to where I started bisecting.  I would much prefer to just have a git bisect stop command, which just stops the bisecting process, but leaves me where I am (like a shortcut to git bisect reset HEAD).  This would be much more symmetric with git bisect start.\n\nIf more people want it, yeah, we can create such a shortcut. But you\ncan also use a git alias for that.\n\n> While we are on the topic of bisecting, I have another issue.  Can we remove the restriction that a \"bad\" commit come after a \"good\" commit?  I'd say about 70% of the time I use bisect to find a commit that fixes a bug, not breaks it.  Whenever this happens, I have to bend my mind over backwards to remind myself that the good behavior is really \"bad\" and the bad behavior is really \"good\".  Is there a reason that git bisect can't just introspect from which comes earlier and which comes later to see which is \"good\" or \"bad\" (instead of just raising an error when they are in the \"wrong\" order)?\n\nYeah, many people find it difficult to reverse the meaning of \"bad\"\nand \"good\" when looking for a fix. There were some suggestions at some\npoints to do something about it. Some of the suggestions were to use\nsome aliases for \"good\" and \"bad\", but there was no agreement. Other\nsuggestions had a patch attached but the patch was not good enough or\nsomething.\n\nAnyway, the restriction is that the \"bad\" commit cannot be an ancestor\nof a \"good\" commit. But the \"good\" commits need not be all ancestors\nof the \"bad\" commit. For example if you have a \"master\" branch and a\n\"dev\" branch that was forked from the \"master\" branch at one point,\nlike that:\n\nA-B-C-D-E <-- master\n \\F-G <-- dev\n\nyou can use one of the branch as \"bad\" and the other one as \"good\".\nAnd that means that in this case we cannot automatically reverse the\nmeaning of \"good\" and \"bad\".\n\nSo if we ever implement a \"--reverse\" mode, I think that the best we\ncould do if we detect that a \"bad\" commit is an ancestor of a \"good\"\ncommit is to suggest the use of this \"--reverse\" mode. Or we could ask\nand use this mode if the answer is yes.\n\nBest regards,\nChristian.\n"},{"id":"159554","messageId":"20110117115133.GA29207@burratino","threadId":"26287","inReplyTo":"AANLkTikNzpCwEieV8sXXctMm+DR69fkLfCF+F3xB6b-k@mail.gmail.com","subject":"Re: git bisect problems/ideas","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-01-17T11:51:33Z","receivedAt":"2011-01-17T11:51:33Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\n> Aaron S. Meurer wrote:\n\n>> 90% of the time I do not\n>> want to go back to where I started bisecting.  I would much prefer to just\n>> have a git bisect stop command\n[which does \"git bisect reset HEAD\"]\n\nFWIW I like the idea. I end up using \"git bisect reset\" by accident\nfrom time to time and it is almost never what I want, especially\nafter working on something else for a few days[1].\n\nMy only worry is that it could be confusing --- what if a person,\nintending to run \"git bisect reset\", runs \"git bisect stop\" instead?\nTo mitigate that, the stop subcommand could print the name of the\nstart commit so such a user knows what to check out to get back to\na familiar state.\n\nChristian Couder wrote:\n\n> Yeah, many people find it difficult to reverse the meaning of \"bad\"\n> and \"good\" when looking for a fix. There were some suggestions at some\n> points to do something about it. Some of the suggestions were to use\n> some aliases for \"good\" and \"bad\", but there was no agreement. Other\n> suggestions had a patch attached but the patch was not good enough or\n> something.\n\nAny pointers to such a discussion or patch? Maybe whatever small\ndetail caused it to be forgotten could be fixed...\n\nCiao,\nJonathan\n\n[1] compare am --abort:\nhttp://thread.gmane.org/gmane.comp.version-control.git/164002\n"},{"id":"159555","messageId":"20110117133843.GA23625@neumann","threadId":"26287","inReplyTo":"20110117115133.GA29207@burratino","subject":"Re: git bisect problems/ideas","fromName":"SZEDER Gábor","fromEmail":"szeder@ira.uka.de","sentAt":"2011-01-17T13:38:44Z","receivedAt":"2011-01-17T13:38:44Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"\nOn Mon, Jan 17, 2011 at 05:51:33AM -0600, Jonathan Nieder wrote:\n> Christian Couder wrote:\n> \n> > Yeah, many people find it difficult to reverse the meaning of \"bad\"\n> > and \"good\" when looking for a fix. There were some suggestions at some\n> > points to do something about it. Some of the suggestions were to use\n> > some aliases for \"good\" and \"bad\", but there was no agreement. Other\n> > suggestions had a patch attached but the patch was not good enough or\n> > something.\n> \n> Any pointers to such a discussion or patch? Maybe whatever small\n> detail caused it to be forgotten could be fixed...\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/86063\n\n\nBest,\nGábor\n"},{"id":"159557","messageId":"54DED602-0BA7-4462-AC00-1DDEEF83068C@gmail.com","threadId":"26287","inReplyTo":"AANLkTikNzpCwEieV8sXXctMm+DR69fkLfCF+F3xB6b-k@mail.gmail.com","subject":"Re: git bisect problems/ideas","fromName":"Aaron S. Meurer","fromEmail":"asmeurer@gmail.com","sentAt":"2011-01-17T18:23:19Z","receivedAt":"2011-01-17T18:23:19Z","isPatch":false,"sender":{"key":"asmeurer@gmail.com","avatar":"https://gravatar.com/avatar/d8229a7558fef02a1f7987c4a3d7aa29d8b14145b21481d6a23c0fb02e73d9e7?d=mp&s=160"},"body":"On Jan 17, 2011, at 2:38 AM, Christian Couder wrote:\n\n> Hi,\n>\n> On Sat, Jan 15, 2011 at 8:33 AM, Aaron S. Meurer \n> wrote:\n>> First off, do you guys have an issue tracker?\n>\n> No, we don't. We use the mailing list.\n>\n\nWell that's amazing to me. How on Earth fo you manage stuff?\n\n>> I asked on IRC, and someone told me that he didn't think you did, \n>> and to just post here. After searching your websites, as far as I \n>> can tell he was right, though this is amazing to me that you can \n>> handle a project like this without an issue tracker. If you guys \n>> really do, then sorry. I would rather post this there than here \n>> (though if you really do, please make it more findable!)\n>>\n>> I just noticed this error/bug:\n>>\n>> git checkout test\n>> git bisect start\n>> \n>> git branch -D test\n>> \n>> git bisect reset\n>>\n>> And it gives an error, because test has been deleted. This is in \n>> 1.7.3.5. Now, I looked through the log of the current master of \n>> git to see if anything has been done about this, and all I noticed \n>> was the commit 3bb8cf88247db5, which essentially improves the error \n>> message.\n>>\n>> Now, this is good, because it seemed to me above that I was stuck \n>> bisecting until I recreated the test branch. I did not realize the \n>> git bisect syntax until later.\n>\n> You mean \"git bisect reset \".\n>\n\nYes, of course. :)\n\n\n>> But this has brought me to bother you guys about something that has \n>> been bugging me for a while. I hate git bisect reset. 90% of the \n>> time I do not want to go back to where I started bisecting. I \n>> would much prefer to just have a git bisect stop command, which \n>> just stops the bisecting process, but leaves me where I am (like a \n>> shortcut to git bisect reset HEAD). This would be much more \n>> symmetric with git bisect start.\n>\n> If more people want it, yeah, we can create such a shortcut. But you\n> can also use a git alias for that.\n>\n\nCan you alias \"git bisect stop\", or would you have to alias \"git \nbisect-stop\"?\n\n>> While we are on the topic of bisecting, I have another issue. Can \n>> we remove the restriction that a \"bad\" commit come after a \"good\" \n>> commit? I'd say about 70% of the time I use bisect to find a \n>> commit that fixes a bug, not breaks it. Whenever this happens, I \n>> have to bend my mind over backwards to remind myself that the good \n>> behavior is really \"bad\" and the bad behavior is really \"good\". Is \n>> there a reason that git bisect can't just introspect from which \n>> comes earlier and which comes later to see which is \"good\" or \n>> \"bad\" (instead of just raising an error when they are in the \n>> \"wrong\" order)?\n>\n> Yeah, many people find it difficult to reverse the meaning of \"bad\"\n> and \"good\" when looking for a fix. There were some suggestions at some\n> points to do something about it. Some of the suggestions were to use\n> some aliases for \"good\" and \"bad\", but there was no agreement. Other\n> suggestions had a patch attached but the patch was not good enough or\n> something.\n>\n> Anyway, the restriction is that the \"bad\" commit cannot be an ancestor\n> of a \"good\" commit. But the \"good\" commits need not be all ancestors\n> of the \"bad\" commit. For example if you have a \"master\" branch and a\n> \"dev\" branch that was forked from the \"master\" branch at one point,\n> like that:\n>\n> A-B-C-D-E <-- master\n> \\F-G <-- dev\n>\n\nI don't understand how this can only be one way? Isn't this \nsymmetric? In other words, how is it different from\n\nA-B-C-D-E <-- dev\n \\F-G <-- master\n\nas far as bisect is concerned? Or maybe I am not entirely clear on \nwhat you are saying.\n\n> you can use one of the branch as \"bad\" and the other one as \"good\".\n> And that means that in this case we cannot automatically reverse the\n> meaning of \"good\" and \"bad\".\n>\n> So if we ever implement a \"--reverse\" mode, I think that the best we\n> could do if we detect that a \"bad\" commit is an ancestor of a \"good\"\n> commit is to suggest the use of this \"--reverse\" mode. Or we could ask\n> and use this mode if the answer is yes.\n>\n> Best regards,\n> Christian.\n\nThis would be an acceptable solution to me (--reverse with asking).\n\nAaron Meurer\n"},{"id":"159558","messageId":"DFADB509-B086-4BF3-AB3B-B19CB68FA113@gmail.com","threadId":"26287","inReplyTo":"20110117115133.GA29207@burratino","subject":"Re: git bisect problems/ideas","fromName":"Aaron S. Meurer","fromEmail":"asmeurer@gmail.com","sentAt":"2011-01-17T18:27:20Z","receivedAt":"2011-01-17T18:27:20Z","isPatch":false,"sender":{"key":"asmeurer@gmail.com","avatar":"https://gravatar.com/avatar/d8229a7558fef02a1f7987c4a3d7aa29d8b14145b21481d6a23c0fb02e73d9e7?d=mp&s=160"},"body":"On Jan 17, 2011, at 4:51 AM, Jonathan Nieder wrote:\n\n> Hi,\n>\n>> Aaron S. Meurer wrote:\n>\n>>> 90% of the time I do not\n>>> want to go back to where I started bisecting. I would much prefer \n>>> to just\n>>> have a git bisect stop command\n> [which does \"git bisect reset HEAD\"]\n>\n> FWIW I like the idea. I end up using \"git bisect reset\" by accident\n> from time to time and it is almost never what I want, especially\n> after working on something else for a few days[1].\n>\n\nThings never get quite that bad for me brcause I gave the git_ps1 in \nmy $PS1, so it tells me when I am bisecting and so I never forget to \nreset soon after I am done. Ditto for am.\n\nAaron Meurer\n\n> My only worry is that it could be confusing --- what if a person,\n> intending to run \"git bisect reset\", runs \"git bisect stop\" instead?\n> To mitigate that, the stop subcommand could print the name of the\n> start commit so such a user knows what to check out to get back to\n> a familiar state.\n>\n> Christian Couder wrote:\n>\n>> Yeah, many people find it difficult to reverse the meaning of \"bad\"\n>> and \"good\" when looking for a fix. There were some suggestions at \n>> some\n>> points to do something about it. Some of the suggestions were to use\n>> some aliases for \"good\" and \"bad\", but there was no agreement. Other\n>> suggestions had a patch attached but the patch was not good enough or\n>> something.\n>\n> Any pointers to such a discussion or patch? Maybe whatever small\n> detail caused it to be forgotten could be fixed...\n>\n> Ciao,\n> Jonathan\n>\n> [1] compare am --abort:\n> http://thread.gmane.org/gmane.comp.version-control.git/164002\n"},{"id":"159561","messageId":"20110117205542.GA21507@burratino","threadId":"26287","inReplyTo":"20110117133843.GA23625@neumann","subject":"Re: git bisect problems/ideas","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-01-17T20:55:42Z","receivedAt":"2011-01-17T20:55:42Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"SZEDER Gábor wrote:\n> On Mon, Jan 17, 2011 at 05:51:33AM -0600, Jonathan Nieder wrote:\n>> Christian Couder wrote:\n\n>>> Yeah, many people find it difficult to reverse the meaning of \"bad\"\n>>> and \"good\" when looking for a fix. There were some suggestions at some\n>>> points to do something about it. Some of the suggestions were to use\n>>> some aliases for \"good\" and \"bad\", but there was no agreement. Other\n>>> suggestions had a patch attached but the patch was not good enough or\n>>> something.\n>>\n>> Any pointers to such a discussion or patch? Maybe whatever small\n>> detail caused it to be forgotten could be fixed...\n>\n> http://thread.gmane.org/gmane.comp.version-control.git/86063\n\nA better link for those who are thinking of picking up the topic might\nbe [1].\n\nThe problems were:\n\n - error messages refer to \"good\" and \"bad\" with the original,\n unreversed meaning, which could be confusing (but see later in the\n thread!).\n - \"git bisect visualize\" doesn't get the memo about the new worldview.\n - it seems that some people lost interest after a while.\n\nNone of these seems totally fatal --- as a new feature, it would not\nbe breaking anyone's workflow, especially if the potentially confusing\nbits are clearly documented.\n\nThanks.\n\n[1] http://thread.gmane.org/gmane.comp.version-control.git/86089/focus=86161\n"},{"id":"159575","messageId":"AANLkTi=A2Twepg3Jo_VYxtvghkhx6ixcpRH3332BoRQo@mail.gmail.com","threadId":"26287","inReplyTo":"54DED602-0BA7-4462-AC00-1DDEEF83068C@gmail.com","subject":"Re: git bisect problems/ideas","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2011-01-18T09:04:29Z","receivedAt":"2011-01-18T09:04:29Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Mon, Jan 17, 2011 at 7:23 PM, Aaron S. Meurer wrote:\n> On Jan 17, 2011, at 2:38 AM, Christian Couder \n> wrote:\n>\n>> Hi,\n>>\n>> On Sat, Jan 15, 2011 at 8:33 AM, Aaron S. Meurer \n>> wrote:\n>>>\n>>> First off, do you guys have an issue tracker?\n>>\n>> No, we don't. We use the mailing list.\n>>\n>\n> Well that's amazing to me. How on Earth fo you manage stuff?\n\nWell, bugs are usually fixed within days after they have been\nreported. Otherwise they are usually documented in the code or in the\ndocumentation or in the test suite (with test_expect_failure).\n\nFor the rest we rely on people remembering what happened and on\npeople's mailing list searching skills ;-)\n\n>> If more people want it, yeah, we can create such a shortcut. But you\n>> can also use a git alias for that.\n>>\n>\n> Can you alias \"git bisect stop\", or would you have to alias \"git\n> bisect-stop\"?\n\nI think you have to alias \"git bisect-stop\".\n\nI am not sure because when I use aliases I prefer to use shell aliases like:\n\nalias gst='git status'\n\n>> Yeah, many people find it difficult to reverse the meaning of \"bad\"\n>> and \"good\" when looking for a fix. There were some suggestions at some\n>> points to do something about it. Some of the suggestions were to use\n>> some aliases for \"good\" and \"bad\", but there was no agreement. Other\n>> suggestions had a patch attached but the patch was not good enough or\n>> something.\n>>\n>> Anyway, the restriction is that the \"bad\" commit cannot be an ancestor\n>> of a \"good\" commit. But the \"good\" commits need not be all ancestors\n>> of the \"bad\" commit. For example if you have a \"master\" branch and a\n>> \"dev\" branch that was forked from the \"master\" branch at one point,\n>> like that:\n>>\n>> A-B-C-D-E <-- master\n>>     \\F-G <-- dev\n>>\n>\n> I don't understand how this can only be one way?  Isn't this symmetric?  In\n> other words, how is it different from\n>\n> A-B-C-D-E <-- dev\n>    \\F-G <-- master\n>\n> as far as bisect is concerned? Or maybe I am not entirely clear on what you\n> are saying.\n\nYes, it is symmetric, so we cannot just automatically reverse the\nmeanning because there is no \"after\" or \"before\" relationship between\n\"dev\" and \"master\".\n\nBest regards,\nChristian.\n"},{"id":"159576","messageId":"AANLkTimQm02VQw19dV8BvZEm=643hbSh2qkvOCEwUOPr@mail.gmail.com","threadId":"26287","inReplyTo":"20110117205542.GA21507@burratino","subject":"Re: git bisect problems/ideas","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2011-01-18T09:05:33Z","receivedAt":"2011-01-18T09:05:33Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"2011/1/17 Jonathan Nieder :\n> SZEDER Gábor wrote:\n>> On Mon, Jan 17, 2011 at 05:51:33AM -0600, Jonathan Nieder wrote:\n>>> Christian Couder wrote:\n>\n>>>> Yeah, many people find it difficult to reverse the meaning of \"bad\"\n>>>> and \"good\" when looking for a fix. There were some suggestions at some\n>>>> points to do something about it. Some of the suggestions were to use\n>>>> some aliases for \"good\" and \"bad\", but there was no agreement. Other\n>>>> suggestions had a patch attached but the patch was not good enough or\n>>>> something.\n>>>\n>>> Any pointers to such a discussion or patch?  Maybe whatever small\n>>> detail caused it to be forgotten could be fixed...\n>>\n>> http://thread.gmane.org/gmane.comp.version-control.git/86063\n\nThanks for the link.\n\n> A better link for those who are thinking of picking up the topic might\n> be [1].\n>\n> The problems were:\n>\n>  - error messages refer to \"good\" and \"bad\" with the original,\n>   unreversed meaning, which could be confusing (but see later in the\n>   thread!).\n>  - \"git bisect visualize\" doesn't get the memo about the new worldview.\n>  - it seems that some people lost interest after a while.\n>\n> None of these seems totally fatal --- as a new feature, it would not\n> be breaking anyone's workflow, especially if the potentially confusing\n> bits are clearly documented.\n\nYeah, some things have changed since that time, so it may be more\ninvolved now, but otherwise I think it would be good to have.\n\nThanks,\nChristian.\n"},{"id":"159589","messageId":"7vd3nukqn8.fsf@alter.siamese.dyndns.org","threadId":"26287","inReplyTo":"AANLkTi=A2Twepg3Jo_VYxtvghkhx6ixcpRH3332BoRQo@mail.gmail.com","subject":"Re: git bisect problems/ideas","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-01-18T18:34:03Z","receivedAt":"2011-01-18T18:34:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Christian Couder writes:\n\n> Well, bugs are usually fixed within days after they have been\n> reported. Otherwise they are usually documented in the code or in the\n> documentation or in the test suite (with test_expect_failure).\n>\n> For the rest we rely on people remembering what happened and on\n> people's mailing list searching skills ;-)\n\nNot really.\n\nWhat we do is to take advantage of the fact that issues people do care\nabout are important ones, and others that nobody cares about are not worth\npursuing.\n\nIn a sense, \"people forgetting\" is a lot more important than \"people\nremembering\" to filter unimportant issues (issues that are so unimportant\nthat even the original complainer does not bother to come back and\nre-raise it).\n"},{"id":"159646","messageId":"AANLkTintdDZ_WZYcM77eMbhBOaEShkELuZ5wuMCQ_3M=@mail.gmail.com","threadId":"26287","inReplyTo":"7vd3nukqn8.fsf@alter.siamese.dyndns.org","subject":"Re: git bisect problems/ideas","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2011-01-19T13:15:13Z","receivedAt":"2011-01-19T13:15:13Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Tue, Jan 18, 2011 at 7:34 PM, Junio C Hamano wrote:\n> Christian Couder writes:\n>\n>> Well, bugs are usually fixed within days after they have been\n>> reported. Otherwise they are usually documented in the code or in the\n>> documentation or in the test suite (with test_expect_failure).\n>>\n>> For the rest we rely on people remembering what happened and on\n>> people's mailing list searching skills ;-)\n>\n> Not really.\n>\n> What we do is to take advantage of the fact that issues people do care\n> about are important ones, and others that nobody cares about are not worth\n> pursuing.\n>\n> In a sense, \"people forgetting\" is a lot more important than \"people\n> remembering\" to filter unimportant issues (issues that are so unimportant\n> that even the original complainer does not bother to come back and\n> re-raise it).\n\nThanks for the clarification, now I feel much better about how well I\nam doing regarding the mailing list :-)\nChristian.\n"},{"id":"159656","messageId":"0F4E18EC-E67D-4C3E-BB5C-C8D8BA326C1D@gmail.com","threadId":"26287","inReplyTo":"7vd3nukqn8.fsf@alter.siamese.dyndns.org","subject":"Re: git bisect problems/ideas","fromName":"Aaron S. Meurer","fromEmail":"asmeurer@gmail.com","sentAt":"2011-01-19T19:15:15Z","receivedAt":"2011-01-19T19:15:15Z","isPatch":false,"sender":{"key":"asmeurer@gmail.com","avatar":"https://gravatar.com/avatar/d8229a7558fef02a1f7987c4a3d7aa29d8b14145b21481d6a23c0fb02e73d9e7?d=mp&s=160"},"body":"So if I care about this issue I should keep bumping it until it gets fixed?\n\nAaron Meurer\n\nOn Jan 18, 2011, at 11:34 AM, Junio C Hamano wrote:\n\n> Christian Couder writes:\n> \n>> Well, bugs are usually fixed within days after they have been\n>> reported. Otherwise they are usually documented in the code or in the\n>> documentation or in the test suite (with test_expect_failure).\n>> \n>> For the rest we rely on people remembering what happened and on\n>> people's mailing list searching skills ;-)\n> \n> Not really.\n> \n> What we do is to take advantage of the fact that issues people do care\n> about are important ones, and others that nobody cares about are not worth\n> pursuing.\n> \n> In a sense, \"people forgetting\" is a lot more important than \"people\n> remembering\" to filter unimportant issues (issues that are so unimportant\n> that even the original complainer does not bother to come back and\n> re-raise it).\n"},{"id":"159659","messageId":"7vzkqwsndm.fsf@alter.siamese.dyndns.org","threadId":"26287","inReplyTo":"0F4E18EC-E67D-4C3E-BB5C-C8D8BA326C1D@gmail.com","subject":"Re: git bisect problems/ideas","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-01-19T19:29:41Z","receivedAt":"2011-01-19T19:29:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Aaron S. Meurer\" writes:\n\n> So if I care about this issue I should keep bumping it until it gets fixed?\n\nDepends on your definition of \"bumping\". If it means \"whining repeatedly\nwithout adding anything to help resolving the issue\", then no.\n\nI thought the previous discussion was stuck after a small step by Dscho in\nthe right direction because nobody followed through?\n"},{"id":"159663","messageId":"0253BAE3-90F7-492C-ADF5-8B16DFFA1E44@gmail.com","threadId":"26287","inReplyTo":"AANLkTi=A2Twepg3Jo_VYxtvghkhx6ixcpRH3332BoRQo@mail.gmail.com","subject":"Re: git bisect problems/ideas","fromName":"Aaron S. Meurer","fromEmail":"asmeurer@gmail.com","sentAt":"2011-01-19T19:44:57Z","receivedAt":"2011-01-19T19:44:57Z","isPatch":false,"sender":{"key":"asmeurer@gmail.com","avatar":"https://gravatar.com/avatar/d8229a7558fef02a1f7987c4a3d7aa29d8b14145b21481d6a23c0fb02e73d9e7?d=mp&s=160"},"body":">>> Yeah, many people find it difficult to reverse the meaning of \"bad\"\n>>> and \"good\" when looking for a fix. There were some suggestions at some\n>>> points to do something about it. Some of the suggestions were to use\n>>> some aliases for \"good\" and \"bad\", but there was no agreement. Other\n>>> suggestions had a patch attached but the patch was not good enough or\n>>> something.\n>>> \n>>> Anyway, the restriction is that the \"bad\" commit cannot be an ancestor\n>>> of a \"good\" commit. But the \"good\" commits need not be all ancestors\n>>> of the \"bad\" commit. For example if you have a \"master\" branch and a\n>>> \"dev\" branch that was forked from the \"master\" branch at one point,\n>>> like that:\n>>> \n>>> A-B-C-D-E <-- master\n>>> \\F-G <-- dev\n>>> \n>> \n>> I don't understand how this can only be one way? Isn't this symmetric? In\n>> other words, how is it different from\n>> \n>> A-B-C-D-E <-- dev\n>> \\F-G <-- master\n>> \n>> as far as bisect is concerned? Or maybe I am not entirely clear on what you\n>> are saying.\n> \n> Yes, it is symmetric, so we cannot just automatically reverse the\n> meanning because there is no \"after\" or \"before\" relationship between\n> \"dev\" and \"master\".\n> \n> Best regards,\n> Christian.\n\n\nI think I understand. What if something works in A, gets broken in C, stays broken in E, but gets fixed in G? Should it maybe be implied by whichever one is marked as good first, A or G, if you trying to find the fix or the break?\n\nIf no, I think --reverse is actually a suitable fix.\n\nAaron Meurer"},{"id":"159744","messageId":"AANLkTikG6Ft3Y922Aaakf28cnYs26PcRHoq9GSNj04mu@mail.gmail.com","threadId":"26287","inReplyTo":"0253BAE3-90F7-492C-ADF5-8B16DFFA1E44@gmail.com","subject":"Re: git bisect problems/ideas","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2011-01-21T13:18:20Z","receivedAt":"2011-01-21T13:18:20Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Wed, Jan 19, 2011 at 8:44 PM, Aaron S. Meurer wrote:\n>>>\n>>> I don't understand how this can only be one way?  Isn't this symmetric?  In\n>>> other words, how is it different from\n>>>\n>>> A-B-C-D-E <-- dev\n>>>    \\F-G <-- master\n>>>\n>>> as far as bisect is concerned? Or maybe I am not entirely clear on what you\n>>> are saying.\n>>\n>> Yes, it is symmetric, so we cannot just automatically reverse the\n>> meanning because there is no \"after\" or \"before\" relationship between\n>> \"dev\" and \"master\".\n>\n> I think I understand.  What if something works in A, gets broken in C, stays broken in E, but gets fixed in G?  Should it maybe be implied by whichever one is marked as good first, A or G, if you trying to find the fix or the break?\n\nIn this case, if we are given \"git bisect bad E\" and \"git bisect good\nA\", yes, as A is before E, we must suppose that we are looking for the\nbreak.\n\nBut if we are given \"git bisect bad E\" and \"git bisect good G\", we\nhave to suppose that we are looking for the break too. There are many\ngood reasons for that:\n\n- it's the logical default for bisect,\n- if what is wanted is the fix, there has been for a long time the\npossibility to just switch \"bad\" and \"good\",\n- the user might not even realize that E and G have no \"after\" or\n\"before\" relationship.\n\n> If no, I think --reverse is actually a suitable fix.\n\nYeah, but I think that what Dscho started was probably better. The\nproblem is just that it is not so simple to implement and no one yet\nhas been interested enough or took enough time to finish it.\n\nBest regards,\nChristian.\n"},{"id":"159774","messageId":"201101212304.36741.j6t@kdbg.org","threadId":"26287","inReplyTo":"AANLkTikG6Ft3Y922Aaakf28cnYs26PcRHoq9GSNj04mu@mail.gmail.com","subject":"Re: git bisect problems/ideas","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2011-01-21T22:04:35Z","receivedAt":"2011-01-21T22:04:35Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"On Freitag, 21. Januar 2011, Christian Couder wrote:\n> On Wed, Jan 19, 2011 at 8:44 PM, Aaron S. Meurer wrote:\n> > If no, I think --reverse is actually a suitable fix.\n>\n> Yeah, but I think that what Dscho started was probably better. The\n> problem is just that it is not so simple to implement and no one yet\n> has been interested enough or took enough time to finish it.\n\nLet me throw in an idea:\n\nAdd two new sub-commands:\n\n* 'git bisect regression': this is a synonym for 'git bisect start'.\n\n* 'git bisect improvement': this also starts a bisection, but subsequently the \noperation of 'git bisect good' and 'git bisect bad' is reversed.\n\n-- Hannes\n"},{"id":"159788","messageId":"m3d3npat5c.fsf@localhost.localdomain","threadId":"26287","inReplyTo":"201101212304.36741.j6t@kdbg.org","subject":"Re: git bisect problems/ideas","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-01-22T14:52:34Z","receivedAt":"2011-01-22T14:52:34Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Sixt writes:\n\n> On Freitag, 21. Januar 2011, Christian Couder wrote:\n> > On Wed, Jan 19, 2011 at 8:44 PM, Aaron S. Meurer wrote:\n\n> > > If no, I think --reverse is actually a suitable fix.\n> >\n> > Yeah, but I think that what Dscho started was probably better. The\n> > problem is just that it is not so simple to implement and no one yet\n> > has been interested enough or took enough time to finish it.\n> \n> Let me throw in an idea:\n> \n> Add two new sub-commands:\n> \n> * 'git bisect regression': this is a synonym for 'git bisect start'.\n> \n> * 'git bisect improvement': this also starts a bisection, but subsequently the \n> operation of 'git bisect good' and 'git bisect bad' is reversed.\n\nI like this!\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"}]}