{"thread":{"id":"14123","subject":"[TOY PATCH] git bisect: introduce 'fixed' and 'unfixed'","startedAt":"2008-06-24T14:17:18Z","lastAt":"2008-06-28T17:52:19Z","messageCount":26,"participants":["Johannes Schindelin","Stephan Beyer","Nicolas Pitre","Jeff King","Reini Urban","Daniel Barkalow","SZEDER Gábor","Michael Haggerty","Junio C Hamano","Lea Wiemann","A Large Angry SCM","Karl Hasselström","Christian Couder"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"80902","messageId":"alpine.DEB.1.00.0806241515460.9925@racer","threadId":"14123","inReplyTo":null,"subject":"[TOY PATCH] git bisect: introduce 'fixed' and 'unfixed'","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-06-24T14:17:18Z","receivedAt":"2008-06-24T14:17:18Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nWhen you look for a fix instead of a regression, it can be quite hard\nto twist your brain into choosing the correct bisect command between\n'git bisect bad' and 'git bisect good'.\n\nSo introduce the commands 'git bisect fixed' and 'git bisect unfixed'.\n\nSigned-off-by: Johannes Schindelin \n---\n\n\tWhen Randal talked about this on IRC, I laughed. But I just had \n\tthe case where it took me _three_ attempts at a bisection, only\n\tto give up and write this patchlet.\n\n\tMay it help someone else, too.\n\n git-bisect.sh | 2 ++\n 1 files changed, 2 insertions(+), 0 deletions(-)\n\ndiff --git a/git-bisect.sh b/git-bisect.sh\nindex 8b11107..d833e21 100755\n--- a/git-bisect.sh\n+++ b/git-bisect.sh\n@@ -501,6 +501,8 @@ case \"$#\" in\n *)\n cmd=\"$1\"\n shift\n+ test $cmd = fixed && cmd=bad\n+ test $cmd = unfixed && cmd=good\n case \"$cmd\" in\n help)\n git bisect -h ;;\n-- \n1.5.6.127.g3fb9f\n"},{"id":"80904","messageId":"20080624144254.GG5528@leksak.fem-net","threadId":"14123","inReplyTo":"alpine.DEB.1.00.0806241515460.9925@racer","subject":"Re: [TOY PATCH] git bisect: introduce 'fixed' and 'unfixed'","fromName":"Stephan Beyer","fromEmail":"s-beyer@gmx.net","sentAt":"2008-06-24T14:42:54Z","receivedAt":"2008-06-24T14:42:54Z","isPatch":true,"sender":{"key":"s-beyer@gmx.net","avatar":"https://avatars.githubusercontent.com/u/143889?v=4"},"body":"Hi,\n\n> So introduce the commands 'git bisect fixed' and 'git bisect unfixed'.\n\nAre they intentionally undocumented to not raise confusion?\n\nRegards,\n Stephan\n\n-- \nStephan Beyer , PGP 0x6EDDD207FCC5040F\n"},{"id":"80907","messageId":"alpine.DEB.1.00.0806241555300.9925@racer","threadId":"14123","inReplyTo":"20080624144254.GG5528@leksak.fem-net","subject":"Re: [TOY PATCH] git bisect: introduce 'fixed' and 'unfixed'","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-06-24T14:55:48Z","receivedAt":"2008-06-24T14:55:48Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 24 Jun 2008, Stephan Beyer wrote:\n\n> > So introduce the commands 'git bisect fixed' and 'git bisect unfixed'.\n> \n> Are they intentionally undocumented to not raise confusion?\n\nUmm. Which part of \"TOY\" is unclear?\n\nCiao,\nDscho\n"},{"id":"80908","messageId":"alpine.LFD.1.10.0806241101160.2979@xanadu.home","threadId":"14123","inReplyTo":"alpine.DEB.1.00.0806241515460.9925@racer","subject":"Re: [TOY PATCH] git bisect: introduce 'fixed' and 'unfixed'","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2008-06-24T15:02:17Z","receivedAt":"2008-06-24T15:02:17Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 24 Jun 2008, Johannes Schindelin wrote:\n\n> \n> When you look for a fix instead of a regression, it can be quite hard\n> to twist your brain into choosing the correct bisect command between\n> 'git bisect bad' and 'git bisect good'.\n> \n> So introduce the commands 'git bisect fixed' and 'git bisect unfixed'.\n\nI really like it. And yes, I know what you mean.\n\n\nNicolas\n"},{"id":"80909","messageId":"20080624151630.GH5528@leksak.fem-net","threadId":"14123","inReplyTo":"alpine.DEB.1.00.0806241555300.9925@racer","subject":"Re: [TOY PATCH] git bisect: introduce 'fixed' and 'unfixed'","fromName":"Stephan Beyer","fromEmail":"s-beyer@gmx.net","sentAt":"2008-06-24T15:16:30Z","receivedAt":"2008-06-24T15:16:30Z","isPatch":true,"sender":{"key":"s-beyer@gmx.net","avatar":"https://avatars.githubusercontent.com/u/143889?v=4"},"body":"> > > So introduce the commands 'git bisect fixed' and 'git bisect unfixed'.\n> > \n> > Are they intentionally undocumented to not raise confusion?\n> \n> Umm. Which part of \"TOY\" is unclear?\n\nThe T, O and Y.\nNo; after searching for \"TOY PATCH\" on gmane: none :)\n\nRegards.\n\n-- \nStephan Beyer , PGP 0x6EDDD207FCC5040F\n"},{"id":"80921","messageId":"20080624163810.GA4654@sigill.intra.peff.net","threadId":"14123","inReplyTo":"alpine.DEB.1.00.0806241515460.9925@racer","subject":"Re: [TOY PATCH] git bisect: introduce 'fixed' and 'unfixed'","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-06-24T16:38:10Z","receivedAt":"2008-06-24T16:38:10Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jun 24, 2008 at 03:17:18PM +0100, Johannes Schindelin wrote:\n\n> When you look for a fix instead of a regression, it can be quite hard\n> to twist your brain into choosing the correct bisect command between\n> 'git bisect bad' and 'git bisect good'.\n> \n> So introduce the commands 'git bisect fixed' and 'git bisect unfixed'.\n\nThanks. This just bit me the other day, and I thought of the same\nsolution. I think it might be worth a \"non-toy\" patch.\n\n-Peff\n"},{"id":"80923","messageId":"alpine.DEB.1.00.0806241750030.9925@racer","threadId":"14123","inReplyTo":"20080624163810.GA4654@sigill.intra.peff.net","subject":"Re: [TOY PATCH] git bisect: introduce 'fixed' and 'unfixed'","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-06-24T16:50:38Z","receivedAt":"2008-06-24T16:50:38Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 24 Jun 2008, Jeff King wrote:\n\n> On Tue, Jun 24, 2008 at 03:17:18PM +0100, Johannes Schindelin wrote:\n> \n> > When you look for a fix instead of a regression, it can be quite hard\n> > to twist your brain into choosing the correct bisect command between\n> > 'git bisect bad' and 'git bisect good'.\n> > \n> > So introduce the commands 'git bisect fixed' and 'git bisect unfixed'.\n> \n> Thanks. This just bit me the other day, and I thought of the same\n> solution. I think it might be worth a \"non-toy\" patch.\n\nOkay, that's 3 people who I take the courage from to turn this into a \nproper patch.\n\nCiao,\nDscho\n"},{"id":"80924","messageId":"486126B5.1090909@x-ray.at","threadId":"14123","inReplyTo":"20080624163810.GA4654@sigill.intra.peff.net","subject":"Re: [TOY PATCH] git bisect: introduce 'fixed' and 'unfixed'","fromName":"Reini Urban","fromEmail":"rurban@x-ray.at","sentAt":"2008-06-24T16:54:13Z","receivedAt":"2008-06-24T16:54:13Z","isPatch":true,"sender":{"key":"rurban@x-ray.at","avatar":"https://gravatar.com/avatar/ed0c25f7529f208fb8a0448c3e9b725cb900baeeca241b3beff8586ab35a5206?d=mp&s=160"},"body":"Jeff King schrieb:\n> On Tue, Jun 24, 2008 at 03:17:18PM +0100, Johannes Schindelin wrote:\n> \n>> When you look for a fix instead of a regression, it can be quite hard\n>> to twist your brain into choosing the correct bisect command between\n>> 'git bisect bad' and 'git bisect good'.\n>>\n>> So introduce the commands 'git bisect fixed' and 'git bisect unfixed'.\n> \n> Thanks. This just bit me the other day, and I thought of the same\n> solution. I think it might be worth a \"non-toy\" patch.\n\nMaybe \"notfixed\" is a better wording than \"unfixed\".\n"},{"id":"80928","messageId":"alpine.DEB.1.00.0806241808400.9925@racer","threadId":"14123","inReplyTo":"alpine.DEB.1.00.0806241750030.9925@racer","subject":"[NON-TOY PATCH] git bisect: introduce 'fixed' and 'unfixed'","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-06-24T17:09:28Z","receivedAt":"2008-06-24T17:09:28Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nWhen you look for a fix instead of a regression, it can be quite hard\nto twist your brain into choosing the correct bisect command between\n'git bisect bad' and 'git bisect good'.\n\nSo introduce the commands 'git bisect fixed' and 'git bisect unfixed'.\n\nSigned-off-by: Johannes Schindelin \n---\n\n\tOn Tue, 24 Jun 2008, Johannes Schindelin wrote:\n\n\t> Okay, that's 3 people who I take the courage from to turn this \n\t> into a proper patch.\n\n\tAnd this is my first attempt at a proper patch for it.\n\n\tNow with documentation, and hopefully all places where the\n\tuser is being told about a \"bad\" commit.\n\n Documentation/git-bisect.txt | 16 ++++++++++++++++\n git-bisect.sh | 25 ++++++++++++++++++-------\n 2 files changed, 34 insertions(+), 7 deletions(-)\n\ndiff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt\nindex 3ca0d33..3fb3b11 100644\n--- a/Documentation/git-bisect.txt\n+++ b/Documentation/git-bisect.txt\n@@ -26,6 +26,9 @@ on the subcommand:\n git bisect log\n git bisect run ...\n \n+ git bisect fixed []\n+ git bisect unfixed [...]\n+\n This command uses 'git-rev-list --bisect' option to help drive the\n binary search process to find which change introduced a bug, given an\n old \"good\" commit object name and a later \"bad\" commit object name.\n@@ -76,6 +79,19 @@ bad\", and ask for the next bisection.\n Until you have no more left, and you'll have been left with the first\n bad kernel rev in \"refs/bisect/bad\".\n \n+Searching for fixes instead of regressions\n+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n+\n+Sometimes you need to find a fix, not a regression. The bisection\n+machinery is really the same for this, but it might be tricky to remember\n+to mark a commit \"bad\" when it contains the fix.\n+\n+So synonyms for \"bad\" and \"good\" are available, \"fixed\" and \"unfixed\"\n+respectively.\n+\n+To mark a commit that contains the fix, call \"git bisect fixed\", and\n+\"git bisect unfixed\" if it does not contain the fix.\n+\n Bisect reset\n ~~~~~~~~~~~~\n \ndiff --git a/git-bisect.sh b/git-bisect.sh\nindex 8b11107..6e71e1a 100755\n--- a/git-bisect.sh\n+++ b/git-bisect.sh\n@@ -1,6 +1,6 @@\n #!/bin/sh\n \n-USAGE='[help|start|bad|good|skip|next|reset|visualize|replay|log|run]'\n+USAGE='[help|start|bad|good|fixed|unfixed|skip|next|reset|visualize|replay|log|run]'\n LONG_USAGE='git bisect help\n print this long help message.\n git bisect start [ [...]] [--] [...]\n@@ -24,6 +24,13 @@ git bisect log\n git bisect run ...\n use ... to automatically bisect.\n \n+When not looking for a regression, but a fix instead, you can use\n+\n+git bisect fixed []\n+\tmark as having the fix you are looking for\n+git bisect unfixed []\n+\tmark as not having the fix you are looking for\n+\n Please use \"git help bisect\" to get the full man page.'\n \n OPTIONS_SPEC=\n@@ -216,7 +223,7 @@ bisect_next_check() {\n \tt,,good)\n \t\t# have bad but not good. we could bisect although\n \t\t# this is less optimum.\n-\t\techo >&2 'Warning: bisecting only with a bad commit.'\n+\t\techo >&2 'Warning: bisecting only with a bad (or fixed) commit.'\n \t\tif test -t 0\n \t\tthen\n \t\t\tprintf >&2 'Are you sure [Y/n]? '\n@@ -231,7 +238,7 @@ bisect_next_check() {\n \t\t\tTHEN='then '\n \t\t}\n \t\techo >&2 'You '$THEN'need to give me at least one good' \\\n-\t\t\t'and one bad revisions.'\n+\t\t\t'and one bad (or fixed) revision.'\n \t\techo >&2 '(You can use \"git bisect bad\" and' \\\n \t\t\t'\"git bisect good\" for that.)'\n \t\texit 1 ;;\n@@ -324,7 +331,7 @@ exit_if_skipped_commits () {\n \t_tried=$1\n \tif expr \"$_tried\" : \".*[|].*\" > /dev/null ; then\n \t\techo \"There are only 'skip'ped commit left to test.\"\n-\t\techo \"The first bad commit could be any of:\"\n+\t\techo \"The first bad (or fixed) commit could be any of:\"\n \t\techo \"$_tried\" | tr '[|]' '[\\012]'\n \t\techo \"We cannot bisect more!\"\n \t\texit 2\n@@ -356,7 +363,7 @@ bisect_next() {\n \tfi\n \tif [ \"$bisect_rev\" = \"$bad\" ]; then\n \t\texit_if_skipped_commits \"$bisect_tried\"\n-\t\techo \"$bisect_rev is first bad commit\"\n+\t\techo \"$bisect_rev is first bad (or fixed) commit\"\n \t\tgit diff-tree --pretty $bisect_rev\n \t\texit 0\n \tfi\n@@ -474,7 +481,8 @@ bisect_run () {\n \n cat \"$GIT_DIR/BISECT_RUN\"\n \n- if grep \"first bad commit could be any of\" \"$GIT_DIR/BISECT_RUN\" \\\n+ if grep \"first bad (or fixed) commit could be any of\" \\\n+\t\t\t\"$GIT_DIR/BISECT_RUN\" \\\n \t\t> /dev/null; then\n \t echo >&2 \"bisect run cannot continue any more\"\n \t exit $res\n@@ -486,7 +494,8 @@ bisect_run () {\n \t exit $res\n fi\n \n- if grep \"is first bad commit\" \"$GIT_DIR/BISECT_RUN\" > /dev/null; then\n+ if grep \"is first bad (or fixed) commit\" \\\n+\t\t\"$GIT_DIR/BISECT_RUN\" > /dev/null; then\n \t echo \"bisect run success\"\n \t exit 0;\n fi\n@@ -501,6 +510,8 @@ case \"$#\" in\n *)\n cmd=\"$1\"\n shift\n+ test $cmd = fixed && cmd=bad\n+ test $cmd = unfixed && cmd=good\n case \"$cmd\" in\n help)\n git bisect -h ;;\n-- \n1.5.6.173.gde14c\n"},{"id":"80935","messageId":"20080624174157.GB9500@sigill.intra.peff.net","threadId":"14123","inReplyTo":"alpine.DEB.1.00.0806241808400.9925@racer","subject":"Re: [NON-TOY PATCH] git bisect: introduce 'fixed' and 'unfixed'","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-06-24T17:41:57Z","receivedAt":"2008-06-24T17:41:57Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jun 24, 2008 at 06:09:28PM +0100, Johannes Schindelin wrote:\n\n> \tAnd this is my first attempt at a proper patch for it.\n> \n> \tNow with documentation, and hopefully all places where the\n> \tuser is being told about a \"bad\" commit.\n\nThis looks reasonably sane to me. The only thing I can think of that\nwe're missing is that \"git bisect visualize\" will still show the refs as\n\"bisect/bad\" and \"bisect/good\".\n\nTo fix that, you'd have to ask people to start the bisect by saying \"I\nam bisecting to find a fix, not a breakage.\" And then you could change\nthe refnames and all of the messages as appropriate.\n\n-Peff\n"},{"id":"80956","messageId":"alpine.LNX.1.00.0806241516440.19665@iabervon.org","threadId":"14123","inReplyTo":"20080624174157.GB9500@sigill.intra.peff.net","subject":"Re: [NON-TOY PATCH] git bisect: introduce 'fixed' and 'unfixed'","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-06-24T19:22:02Z","receivedAt":"2008-06-24T19:22:02Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 24 Jun 2008, Jeff King wrote:\n\n> On Tue, Jun 24, 2008 at 06:09:28PM +0100, Johannes Schindelin wrote:\n> \n> > \tAnd this is my first attempt at a proper patch for it.\n> > \n> > \tNow with documentation, and hopefully all places where the\n> > \tuser is being told about a \"bad\" commit.\n> \n> This looks reasonably sane to me. The only thing I can think of that\n> we're missing is that \"git bisect visualize\" will still show the refs as\n> \"bisect/bad\" and \"bisect/good\".\n> \n> To fix that, you'd have to ask people to start the bisect by saying \"I\n> am bisecting to find a fix, not a breakage.\" And then you could change\n> the refnames and all of the messages as appropriate.\n\nThat would also be a good way of taking care of the problem where someone \ngets distracted while running a slow test, forgets what they're looking \nfor, and marks the result as \"bad\" instead of \"unfixed\".\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"80960","messageId":"alpine.DEB.1.00.0806242026441.9925@racer","threadId":"14123","inReplyTo":"alpine.LNX.1.00.0806241516440.19665@iabervon.org","subject":"Re: [NON-TOY PATCH] git bisect: introduce 'fixed' and 'unfixed'","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-06-24T19:26:55Z","receivedAt":"2008-06-24T19:26:55Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 24 Jun 2008, Daniel Barkalow wrote:\n\n> On Tue, 24 Jun 2008, Jeff King wrote:\n> \n> > On Tue, Jun 24, 2008 at 06:09:28PM +0100, Johannes Schindelin wrote:\n> > \n> > > \tAnd this is my first attempt at a proper patch for it.\n> > > \n> > > \tNow with documentation, and hopefully all places where the\n> > > \tuser is being told about a \"bad\" commit.\n> > \n> > This looks reasonably sane to me. The only thing I can think of that\n> > we're missing is that \"git bisect visualize\" will still show the refs as\n> > \"bisect/bad\" and \"bisect/good\".\n> > \n> > To fix that, you'd have to ask people to start the bisect by saying \"I\n> > am bisecting to find a fix, not a breakage.\" And then you could change\n> > the refnames and all of the messages as appropriate.\n> \n> That would also be a good way of taking care of the problem where someone \n> gets distracted while running a slow test, forgets what they're looking \n> for, and marks the result as \"bad\" instead of \"unfixed\".\n\nFeel free to rework my patch.\n\nCiao,\nDscho\n"},{"id":"80970","messageId":"20080624195907.GI8421@neumann","threadId":"14123","inReplyTo":"alpine.DEB.1.00.0806241808400.9925@racer","subject":"Re: [NON-TOY PATCH] git bisect: introduce 'fixed' and 'unfixed'","fromName":"SZEDER Gábor","fromEmail":"szeder@ira.uka.de","sentAt":"2008-06-24T19:59:07Z","receivedAt":"2008-06-24T19:59:07Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Tue, Jun 24, 2008 at 06:09:28PM +0100, Johannes Schindelin wrote:\n> So introduce the commands 'git bisect fixed' and 'git bisect unfixed'.\nAnd maybe this one squashed on it, to add completion support for the\nnew subcommands.\n\n\n---\n contrib/completion/git-completion.bash | 4 +++-\n 1 files changed, 3 insertions(+), 1 deletions(-)\n\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex ebf7cde..014adab 100755\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -511,7 +511,9 @@ _git_add ()\n \n _git_bisect ()\n {\n-\tlocal subcommands=\"start bad good reset visualize replay log\"\n+\tlocal subcommands=\"\n+\t\tstart bad good reset visualize replay log fixed unfixed\n+\t\t\"\n \tlocal subcommand=\"$(__git_find_subcommand \"$subcommands\")\"\n \tif [ -z \"$subcommand\" ]; then\n \t\t__gitcomp \"$subcommands\"\n-- \n1.5.6.64.g7dc1df\n"},{"id":"80972","messageId":"486153DB.3070502@alum.mit.edu","threadId":"14123","inReplyTo":"alpine.DEB.1.00.0806241808400.9925@racer","subject":"Re: [NON-TOY PATCH] git bisect: introduce 'fixed' and 'unfixed'","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2008-06-24T20:06:51Z","receivedAt":"2008-06-24T20:06:51Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"Johannes Schindelin wrote:\n> When you look for a fix instead of a regression, it can be quite hard\n> to twist your brain into choosing the correct bisect command between\n> 'git bisect bad' and 'git bisect good'.\n> \n> So introduce the commands 'git bisect fixed' and 'git bisect unfixed'.\n\nIt seems to me that your problem is that git-bisect requires the \"good\"\nrevision to be older than the \"bad\" one. If this requirement were\nremoved, would there still be a need for \"fixed\" vs. \"unfixed\"?\n\nA bisection search doesn't care what labels are applied to the two\nendpoints, as it only looks for transitions between the labels.\nTherefore it should be easy to teach git-bisect to locate either kind of\ntransition, \"bad\" -> \"good\" or \"good\" -> \"bad\", depending only on where\nthe user places the original \"good\" and \"bad\" tags.\n\nMichael\n"},{"id":"80980","messageId":"alpine.DEB.1.00.0806242137120.9925@racer","threadId":"14123","inReplyTo":"486153DB.3070502@alum.mit.edu","subject":"Re: [NON-TOY PATCH] git bisect: introduce 'fixed' and 'unfixed'","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-06-24T20:38:39Z","receivedAt":"2008-06-24T20:38:39Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 24 Jun 2008, Michael Haggerty wrote:\n\n> Johannes Schindelin wrote:\n> > When you look for a fix instead of a regression, it can be quite hard\n> > to twist your brain into choosing the correct bisect command between\n> > 'git bisect bad' and 'git bisect good'.\n> > \n> > So introduce the commands 'git bisect fixed' and 'git bisect unfixed'.\n> \n> It seems to me that your problem is that git-bisect requires the \"good\" \n> revision to be older than the \"bad\" one. If this requirement were \n> removed, would there still be a need for \"fixed\" vs. \"unfixed\"?\n\nNope.\n\nThe thing that makes \"fixed\" and \"bad\" special is that _one_ commit \nintroduced that.\n\nCiao,\nDscho\n"},{"id":"81000","messageId":"7vej6mbh3w.fsf@gitster.siamese.dyndns.org","threadId":"14123","inReplyTo":"20080624174157.GB9500@sigill.intra.peff.net","subject":"Re: [NON-TOY PATCH] git bisect: introduce 'fixed' and 'unfixed'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-24T22:30:59Z","receivedAt":"2008-06-24T22:30:59Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Tue, Jun 24, 2008 at 06:09:28PM +0100, Johannes Schindelin wrote:\n>\n>> \tAnd this is my first attempt at a proper patch for it.\n>> \n>> \tNow with documentation, and hopefully all places where the\n>> \tuser is being told about a \"bad\" commit.\n>\n> This looks reasonably sane to me. The only thing I can think of that\n> we're missing is that \"git bisect visualize\" will still show the refs as\n> \"bisect/bad\" and \"bisect/good\".\n>\n> To fix that, you'd have to ask people to start the bisect by saying \"I\n> am bisecting to find a fix, not a breakage.\" And then you could change\n> the refnames and all of the messages as appropriate.\n\nIt probably is not just a good idea, but is a necessary fix, to remove\nconfusion like this example that appears everywhere:\n\n> \t\techo >&2 'You '$THEN'need to give me at least one good' \\\n> -\t\t\t'and one bad revisions.'\n> +\t\t\t'and one bad (or fixed) revision.'\n> \t\techo >&2 '(You can use \"git bisect bad\" and' \\\n> \t\t\t'\"git bisect good\" for that.)'\n\nPeople who are reading the change Dscho did in the \"patch\" form may not\nnotice it, but imagine how the above looks to the end user who was told\nthat \"new bisect can now look for fixes\", who does not need to nor even\nwant to know that the new feature is implemented by making bad and fixed\nsynonyms.\n\nThey need to mentally reword \"good\" into \"unfixed\" and \"bisect bad\" into\n\"bisect fixed\" while reading the output from the above pieces, but the\npoint of this new \"look for fixes\" feature is they do not have to do the\nrewording anymore!\n"},{"id":"80998","messageId":"7v8wwubh3j.fsf@gitster.siamese.dyndns.org","threadId":"14123","inReplyTo":"alpine.DEB.1.00.0806242137120.9925@racer","subject":"Re: [NON-TOY PATCH] git bisect: introduce 'fixed' and 'unfixed'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-24T22:31:12Z","receivedAt":"2008-06-24T22:31:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Tue, 24 Jun 2008, Michael Haggerty wrote:\n> ...\n>> It seems to me that your problem is that git-bisect requires the \"good\" \n>> revision to be older than the \"bad\" one. If this requirement were \n>> removed, would there still be a need for \"fixed\" vs. \"unfixed\"?\n>\n> Nope.\n>\n> The thing that makes \"fixed\" and \"bad\" special is that _one_ commit \n> introduced that.\n\nThat was my initial reaction, and I actually was about to phrase it more\nbluntly: you do not understand what \"bisect\" is.\n\nBut that was a reaction without thinking things through. It may not be\nwhat \"git bisect\" currently is, but the suggestion does not go against\nwhat the underlying \"git rev-list --bisect\" is at all. I think what\nMichael is speculating is different, and it makes sense in its own way.\n\nInstead of having a set of bisect/good-* refs and a single bisect-bad ref,\nyour \"fixed and unfixed\" mode could work quite differently. By noticing\nthat the topology the user specified with initial good and bad have\nancient bad and recent good --- that is, \"it used to be bad but now it is\ngood\" --- you could instead use a set of bisect/bad-* refs and a single\nbisect-good ref, and feed good and bad swapped to \"rev-list --bisect\" in\nbisect_next(). That way, the labels given by visualize will match what\nthe user is doing automatically.\n\nI said \"it makes sense in its own way\", because it is _quite_ different\nfrom how git-bisect currently assumes, and restructuring git-bisect to\noperate naturally in a way Michael describes would be a much larger\nsurgery with costs (including risks of bugs) associated with it, which\nneeds to be weighed in when judging that approach would actually make\nsense.\n"},{"id":"81003","messageId":"alpine.LFD.1.10.0806241841150.2979@xanadu.home","threadId":"14123","inReplyTo":"7v8wwubh3j.fsf@gitster.siamese.dyndns.org","subject":"Re: [NON-TOY PATCH] git bisect: introduce 'fixed' and 'unfixed'","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2008-06-24T22:43:44Z","receivedAt":"2008-06-24T22:43:44Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 24 Jun 2008, Junio C Hamano wrote:\n\n> Instead of having a set of bisect/good-* refs and a single bisect-bad ref,\n> your \"fixed and unfixed\" mode could work quite differently. By noticing\n> that the topology the user specified with initial good and bad have\n> ancient bad and recent good --- that is, \"it used to be bad but now it is\n> good\" --- you could instead use a set of bisect/bad-* refs and a single\n> bisect-good ref, and feed good and bad swapped to \"rev-list --bisect\" in\n> bisect_next(). That way, the labels given by visualize will match what\n> the user is doing automatically.\n\n... and the final answer would be \"the first good commit is ...\".\n\nThat would be awesome, much nicer than yet more keywords.\n\n> I said \"it makes sense in its own way\", because it is _quite_ different\n> from how git-bisect currently assumes, and restructuring git-bisect to\n> operate naturally in a way Michael describes would be a much larger\n> surgery with costs (including risks of bugs) associated with it, which\n> needs to be weighed in when judging that approach would actually make\n> sense.\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n> \n\n\nNicolas\n"},{"id":"81005","messageId":"486179C8.2000704@gmail.com","threadId":"14123","inReplyTo":"486153DB.3070502@alum.mit.edu","subject":"Re: [NON-TOY PATCH] git bisect: introduce 'fixed' and 'unfixed'","fromName":"Lea Wiemann","fromEmail":"lewiemann@gmail.com","sentAt":"2008-06-24T22:48:40Z","receivedAt":"2008-06-24T22:48:40Z","isPatch":true,"sender":{"key":"lewiemann@gmail.com","avatar":null},"body":"Michael Haggerty wrote:\n> Therefore it should be easy to teach git-bisect to locate either kind of\n> transition, \"bad\" -> \"good\" or \"good\" -> \"bad\", depending only on where\n> the user places the original \"good\" and \"bad\" tags.\n\nI think this is a good suggestion (though I haven't thought things \nthrough). Another idea is to add \"old\" and \"new\" (or something like \nthat) as aliases to \"good\" and \"bad\", since that's the only semantics \nthat the bisect labels actually seem to have.\n\n-- Lea\n"},{"id":"81026","messageId":"486188E3.10803@gmail.com","threadId":"14123","inReplyTo":"486179C8.2000704@gmail.com","subject":"Re: [NON-TOY PATCH] git bisect: introduce 'fixed' and 'unfixed'","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2008-06-24T23:53:07Z","receivedAt":"2008-06-24T23:53:07Z","isPatch":true,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Lea Wiemann wrote:\n> Michael Haggerty wrote:\n>> Therefore it should be easy to teach git-bisect to locate either kind of\n>> transition, \"bad\" -> \"good\" or \"good\" -> \"bad\", depending only on where\n>> the user places the original \"good\" and \"bad\" tags.\n> \n> I think this is a good suggestion (though I haven't thought things \n> through). Another idea is to add \"old\" and \"new\" (or something like \n> that) as aliases to \"good\" and \"bad\", since that's the only semantics \n> that the bisect labels actually seem to have.\n\n\"Before\" and \"After\" the \"Change\" maybe?\n"},{"id":"81088","messageId":"20080625072733.GA26605@diana.vm.bytemark.co.uk","threadId":"14123","inReplyTo":"486188E3.10803@gmail.com","subject":"Re: [NON-TOY PATCH] git bisect: introduce 'fixed' and 'unfixed'","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2008-06-25T07:27:33Z","receivedAt":"2008-06-25T07:27:33Z","isPatch":true,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2008-06-24 19:53:07 -0400, A Large Angry SCM wrote:\n\n> Lea Wiemann wrote:\n>\n> > I think this is a good suggestion (though I haven't thought things\n> > through). Another idea is to add \"old\" and \"new\" (or something\n> > like that) as aliases to \"good\" and \"bad\", since that's the only\n> > semantics that the bisect labels actually seem to have.\n>\n> \"Before\" and \"After\" the \"Change\" maybe?\n\nHa. It would not be hard to make it accept any two tags the user\nhappens to use. fast/slow, works/broken, fina-fisken/totalkvaddad, ...\nit even comes with built-in internationalization!\n\n/me ducks.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"81238","messageId":"200806260803.20731.chriscool@tuxfamily.org","threadId":"14123","inReplyTo":"7v8wwubh3j.fsf@gitster.siamese.dyndns.org","subject":"Re: [NON-TOY PATCH] git bisect: introduce 'fixed' and 'unfixed'","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2008-06-26T06:03:20Z","receivedAt":"2008-06-26T06:03:20Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Le mercredi 25 juin 2008, Junio C Hamano a écrit :\n> Johannes Schindelin writes:\n> > On Tue, 24 Jun 2008, Michael Haggerty wrote:\n> > ...\n> >\n> >> It seems to me that your problem is that git-bisect requires the\n> >> \"good\" revision to be older than the \"bad\" one. \n\nYes, \"git bisect\" works if the good revisions are ancestors of the bad \nrevision.\n\nCurrently if you mistake good and bad revs (and if one of the rev is\nan ancestor of the other) you get something like:\n\n$ git bisect start HEAD~3 HEAD\n'git rev-list --bisect-vars' failed:\nmaybe you mistake good and bad revs?\n\nI also noticed that if the good and bad are siblings for example like:\n\nA-B-C-D\n \\E-F\n\nand you say:\n\n$ git bisect start D F\n\n(that means D is bad and F is good)\n\nthen it will kind of \"work\" but only C and D will be considered as possible \nfirst bad commits. This is arguably a bug because for example E could have \nfixed a bug that always existed, and then the first bad commit is B or A \ndepending how we define it.\n\n> >> If this requirement \n> >> were removed, would there still be a need for \"fixed\" vs. \"unfixed\"?\n\nWell this requirement can be \"removed\" in different ways.\n\n1) We could just allow anything to be called \"bad\" and \"good\" as long as \nthere is either:\n\n- only one bad revision and all good revisions are its ancestor, or\n- only one good revision and all bad revisions are its ancestor\n\n2) Another way to remove the requirement is to make it work in the siblings \ncase above.\n\n> > Nope.\n> >\n> > The thing that makes \"fixed\" and \"bad\" special is that _one_ commit\n> > introduced that.\n>\n> That was my initial reaction, and I actually was about to phrase it more\n> bluntly: you do not understand what \"bisect\" is.\n>\n> But that was a reaction without thinking things through. It may not be\n> what \"git bisect\" currently is, but the suggestion does not go against\n> what the underlying \"git rev-list --bisect\" is at all.\n\nIf we want to make the siblings case (case 2) work, then \"git \nrev-list --bisect\" needs work though.\n\n> I think what \n> Michael is speculating is different, and it makes sense in its own way.\n>\n> Instead of having a set of bisect/good-* refs and a single bisect-bad\n> ref, your \"fixed and unfixed\" mode could work quite differently. By\n> noticing that the topology the user specified with initial good and bad\n> have ancient bad and recent good --- that is, \"it used to be bad but now\n> it is good\" --- you could instead use a set of bisect/bad-* refs and a\n> single bisect-good ref, and feed good and bad swapped to \"rev-list\n> --bisect\" in bisect_next(). That way, the labels given by visualize will\n> match what the user is doing automatically.\n\nYes, that is the case 1 above.\n\n> I said \"it makes sense in its own way\", because it is _quite_ different\n> from how git-bisect currently assumes, and restructuring git-bisect to\n> operate naturally in a way Michael describes would be a much larger\n> surgery with costs (including risks of bugs) associated with it, which\n> needs to be weighed in when judging that approach would actually make\n> sense.\n\nYes it needs work in git-bisect.sh and I don't think the current situation \nwith the \"maybe you mistake good and bad revs?\" error message is too bad.\n\nRegards,\nChristian.\n"},{"id":"81401","messageId":"alpine.DEB.1.00.0806271446180.9925@racer","threadId":"14123","inReplyTo":"7vej6mbh3w.fsf@gitster.siamese.dyndns.org","subject":"[PATCH, next version] git bisect: introduce 'fixed' and 'unfixed'","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-06-27T13:48:31Z","receivedAt":"2008-06-27T13:48:31Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nWhen you look for a fix instead of a regression, it can be quite hard\nto twist your brain into choosing the correct bisect command between\n'git bisect bad' and 'git bisect good'.\n\nSo introduce the commands 'git bisect fixed' and 'git bisect unfixed'.\n\nSigned-off-by: Johannes Schindelin \n---\n\n\tOn Tue, 24 Jun 2008, Junio C Hamano wrote:\n\n\t> Jeff King writes:\n\t> \n\t> > On Tue, Jun 24, 2008 at 06:09:28PM +0100, Johannes Schindelin \n\t> > wrote:\n\t> >\n\t> >> \tAnd this is my first attempt at a proper patch for it.\n\t> >> \n\t> >> \tNow with documentation, and hopefully all places where the\n\t> >> \tuser is being told about a \"bad\" commit.\n\t> >\n\t> > This looks reasonably sane to me. The only thing I can think \n\t> > of that we're missing is that \"git bisect visualize\" will still\n\t> > show the refs as \"bisect/bad\" and \"bisect/good\".\n\t> >\n\t> > To fix that, you'd have to ask people to start the bisect by \n\t> > saying \"I am bisecting to find a fix, not a breakage.\" And then\n\t> > you could change the refnames and all of the messages as\n\t> > appropriate.\n\t> \n\t> It probably is not just a good idea, but is a necessary fix, to \n\t> remove confusion like this example that appears everywhere:\n\t> \n\t> > \t\techo >&2 'You '$THEN'need to give me at least one good' \\\n\t> > -\t\t\t'and one bad revisions.'\n\t> > +\t\t\t'and one bad (or fixed) revision.'\n\t> > \t\techo >&2 '(You can use \"git bisect bad\" and' \\\n\t> > \t\t\t'\"git bisect good\" for that.)'\n\t> \n\t> People who are reading the change Dscho did in the \"patch\" form \n\t> may not notice it, but imagine how the above looks to the end user\n\t> who was told that \"new bisect can now look for fixes\", who does\n\t> not need to nor even want to know that the new feature is\n\t> implemented by making bad and fixed synonyms.\n\t> \n\t> They need to mentally reword \"good\" into \"unfixed\" and \"bisect \n\t> bad\" into \"bisect fixed\" while reading the output from the above \n\t> pieces, but the point of this new \"look for fixes\" feature is they do \n\t> not have to do the rewording anymore!\n\n\tHow about autodetecting from the user's last input what she meant?\n\n Documentation/git-bisect.txt | 16 ++++++++++++++++\n git-bisect.sh | 42 ++++++++++++++++++++++++++++++------------\n 2 files changed, 46 insertions(+), 12 deletions(-)\n\ndiff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt\nindex 3ca0d33..3fb3b11 100644\n--- a/Documentation/git-bisect.txt\n+++ b/Documentation/git-bisect.txt\n@@ -26,6 +26,9 @@ on the subcommand:\n git bisect log\n git bisect run ...\n \n+ git bisect fixed []\n+ git bisect unfixed [...]\n+\n This command uses 'git-rev-list --bisect' option to help drive the\n binary search process to find which change introduced a bug, given an\n old \"good\" commit object name and a later \"bad\" commit object name.\n@@ -76,6 +79,19 @@ bad\", and ask for the next bisection.\n Until you have no more left, and you'll have been left with the first\n bad kernel rev in \"refs/bisect/bad\".\n \n+Searching for fixes instead of regressions\n+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n+\n+Sometimes you need to find a fix, not a regression. The bisection\n+machinery is really the same for this, but it might be tricky to remember\n+to mark a commit \"bad\" when it contains the fix.\n+\n+So synonyms for \"bad\" and \"good\" are available, \"fixed\" and \"unfixed\"\n+respectively.\n+\n+To mark a commit that contains the fix, call \"git bisect fixed\", and\n+\"git bisect unfixed\" if it does not contain the fix.\n+\n Bisect reset\n ~~~~~~~~~~~~\n \ndiff --git a/git-bisect.sh b/git-bisect.sh\nindex 8b11107..197489b 100755\n--- a/git-bisect.sh\n+++ b/git-bisect.sh\n@@ -1,6 +1,6 @@\n #!/bin/sh\n \n-USAGE='[help|start|bad|good|skip|next|reset|visualize|replay|log|run]'\n+USAGE='[help|start|bad|good|fixed|unfixed|skip|next|reset|visualize|replay|log|run]'\n LONG_USAGE='git bisect help\n print this long help message.\n git bisect start [ [...]] [--] [...]\n@@ -24,6 +24,13 @@ git bisect log\n git bisect run ...\n use ... to automatically bisect.\n \n+When not looking for a regression, but a fix instead, you can use\n+\n+git bisect fixed []\n+\tmark as having the fix you are looking for\n+git bisect unfixed []\n+\tmark as not having the fix you are looking for\n+\n Please use \"git help bisect\" to get the full man page.'\n \n OPTIONS_SPEC=\n@@ -32,6 +39,8 @@ require_work_tree\n \n _x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'\n _x40=\"$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40\"\n+GOOD=\"good\"\n+BAD=\"bad\"\n \n sq() {\n \t@@PERL@@ -e '\n@@ -216,7 +225,7 @@ bisect_next_check() {\n \tt,,good)\n \t\t# have bad but not good. we could bisect although\n \t\t# this is less optimum.\n-\t\techo >&2 'Warning: bisecting only with a bad commit.'\n+\t\techo >&2 'Warning: bisecting only with a $BAD commit.'\n \t\tif test -t 0\n \t\tthen\n \t\t\tprintf >&2 'Are you sure [Y/n]? '\n@@ -230,10 +239,10 @@ bisect_next_check() {\n \t\t\techo >&2 'You need to start by \"git bisect start\".'\n \t\t\tTHEN='then '\n \t\t}\n-\t\techo >&2 'You '$THEN'need to give me at least one good' \\\n-\t\t\t'and one bad revisions.'\n-\t\techo >&2 '(You can use \"git bisect bad\" and' \\\n-\t\t\t'\"git bisect good\" for that.)'\n+\t\techo >&2 'You '$THEN'need to give me at least one $GOOD' \\\n+\t\t\t'and one $BAD revision.'\n+\t\techo >&2 '(You can use \"git bisect $BAD\" and' \\\n+\t\t\t'\"git bisect $GOOD\" for that.)'\n \t\texit 1 ;;\n \tesac\n }\n@@ -250,7 +259,7 @@ eval_rev_list() {\n \n \tif [ $res -ne 0 ]; then\n \t\techo >&2 \"'git rev-list --bisect-vars' failed:\"\n-\t\techo >&2 \"maybe you mistake good and bad revs?\"\n+\t\techo >&2 \"maybe you mistake $GOOD and $BAD revs?\"\n \t\texit $res\n \tfi\n \n@@ -324,7 +333,7 @@ exit_if_skipped_commits () {\n \t_tried=$1\n \tif expr \"$_tried\" : \".*[|].*\" > /dev/null ; then\n \t\techo \"There are only 'skip'ped commit left to test.\"\n-\t\techo \"The first bad commit could be any of:\"\n+\t\techo \"The first $BAD commit could be any of:\"\n \t\techo \"$_tried\" | tr '[|]' '[\\012]'\n \t\techo \"We cannot bisect more!\"\n \t\texit 2\n@@ -351,12 +360,12 @@ bisect_next() {\n \teval \"$eval\" || exit\n \n \tif [ -z \"$bisect_rev\" ]; then\n-\t\techo \"$bad was both good and bad\"\n+\t\techo \"$bad was both $GOOD and $BAD\"\n \t\texit 1\n \tfi\n \tif [ \"$bisect_rev\" = \"$bad\" ]; then\n \t\texit_if_skipped_commits \"$bisect_tried\"\n-\t\techo \"$bisect_rev is first bad commit\"\n+\t\techo \"$bisect_rev is first $BAD commit\"\n \t\tgit diff-tree --pretty $bisect_rev\n \t\texit 0\n \tfi\n@@ -474,7 +483,8 @@ bisect_run () {\n \n cat \"$GIT_DIR/BISECT_RUN\"\n \n- if grep \"first bad commit could be any of\" \"$GIT_DIR/BISECT_RUN\" \\\n+ if grep \"first $BAD commit could be any of\" \\\n+\t\t\t\"$GIT_DIR/BISECT_RUN\" \\\n \t\t> /dev/null; then\n \t echo >&2 \"bisect run cannot continue any more\"\n \t exit $res\n@@ -486,7 +496,8 @@ bisect_run () {\n \t exit $res\n fi\n \n- if grep \"is first bad commit\" \"$GIT_DIR/BISECT_RUN\" > /dev/null; then\n+ if grep \"is first $BAD commit\" \\\n+\t\t\"$GIT_DIR/BISECT_RUN\" > /dev/null; then\n \t echo \"bisect run success\"\n \t exit 0;\n fi\n@@ -502,6 +513,13 @@ case \"$#\" in\n cmd=\"$1\"\n shift\n case \"$cmd\" in\n+ fixed|unfixed)\n+\tBAD=\"fixed\"\n+\tGOOD=\"unfixed\"\n+\ttest \"$cmd\" = fixed && cmd=bad\n+\ttest \"$cmd\" = unfixed && cmd=good\n+ esac\n+ case \"$cmd\" in\n help)\n git bisect -h ;;\n start)\n-- \n1.5.6.173.gde14c\n"},{"id":"81510","messageId":"7vprq2o4zb.fsf@gitster.siamese.dyndns.org","threadId":"14123","inReplyTo":"alpine.DEB.1.00.0806271446180.9925@racer","subject":"Re: [PATCH, next version] git bisect: introduce 'fixed' and 'unfixed'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-27T23:03:36Z","receivedAt":"2008-06-27T23:03:36Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> When you look for a fix instead of a regression, it can be quite hard\n> to twist your brain into choosing the correct bisect command between\n> 'git bisect bad' and 'git bisect good'.\n\nHmm, I do not currently see any differene between master and next version\nof bisect. In what way is this 'next' version?\n\nAside from the 'visualize' issue this does not attempt to address, I\nwonder if it may be a good idea to detect and warn mixed usage as well\n(e.g. \"You earlier said 'bad' but now you are saying 'fixed' -- are you\nsure?\"), and if so if it can be implemented easily.\n"},{"id":"81555","messageId":"alpine.DEB.1.00.0806281446260.9925@racer","threadId":"14123","inReplyTo":"7vprq2o4zb.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH, next version] git bisect: introduce 'fixed' and 'unfixed'","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-06-28T13:48:55Z","receivedAt":"2008-06-28T13:48:55Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 27 Jun 2008, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > When you look for a fix instead of a regression, it can be quite hard \n> > to twist your brain into choosing the correct bisect command between \n> > 'git bisect bad' and 'git bisect good'.\n> \n> Hmm, I do not currently see any differene between master and next version\n> of bisect. In what way is this 'next' version?\n\nIt has a \"BAD\" and a \"GOOD\" variable that are reset to \"fixed\" and \n\"unfixed\" if the user said \"fixed\" or \"unfixed\".\n\n> Aside from the 'visualize' issue this does not attempt to address,\n\nYes, I forgot about that issue, mainly because I do not use it myself...\n\n> I wonder if it may be a good idea to detect and warn mixed usage as well \n> (e.g. \"You earlier said 'bad' but now you are saying 'fixed' -- are you \n> sure?\"), and if so if it can be implemented easily.\n\nHmm. I tried to avoid that, as it would mean a larger patch. But I guess \nyou could write .git/BISECT_TERMS or some such.\n\nBut that, together with the visualize part, would take more time than I am \nwilling to spend on this issue.\n\nWell, I guess I'll leave it then,\nDscho\n"},{"id":"81573","messageId":"7v4p7do3ak.fsf@gitster.siamese.dyndns.org","threadId":"14123","inReplyTo":"alpine.DEB.1.00.0806281446260.9925@racer","subject":"Re: [PATCH, next version] git bisect: introduce 'fixed' and 'unfixed'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-28T17:52:19Z","receivedAt":"2008-06-28T17:52:19Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n>> Johannes Schindelin writes:\n>> \n>> > When you look for a fix instead of a regression, it can be quite hard \n>> > to twist your brain into choosing the correct bisect command between \n>> > 'git bisect bad' and 'git bisect good'.\n>> \n>> Hmm, I do not currently see any differene between master and next version\n>> of bisect. In what way is this 'next' version?\n>\n> It has a \"BAD\" and a \"GOOD\" variable that are reset to \"fixed\" and \n> \"unfixed\" if the user said \"fixed\" or \"unfixed\".\n\nAh, Ok, you did not mean \"this is meant to applied to 'next' branch\", but\nmeant \"[PATCH v$N]\" for some N > 1.\n\n> But that, together with the visualize part, would take more time than I am \n> willing to spend on this issue.\n\nOther people would find itch (or they may not). Either way is fine.\n"}]}