{"thread":{"id":"47168","subject":"[PATCH] bisect: clarify that one can select multiple good commits","startedAt":"2017-11-11T13:26:28Z","lastAt":"2017-11-11T13:46:55Z","messageCount":3,"participants":["Robert P. J. Day","Kevin Daudt"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"332283","messageId":"alpine.LFD.2.21.1711110820370.8941@localhost.localdomain","threadId":"47168","inReplyTo":null,"subject":"[PATCH] bisect: clarify that one can select multiple good commits","fromName":"Robert P. J. Day","fromEmail":"rpjday@crashcourse.ca","sentAt":"2017-11-11T13:26:00Z","receivedAt":"2017-11-11T13:26:28Z","isPatch":true,"sender":{"key":"rpjday@crashcourse.ca","avatar":"https://avatars.githubusercontent.com/u/226084077?v=4"},"body":"\nCurrent man page for \"bisect\" is inconsistent explaining the fact that\n\"git bisect\" takes precisely one bad commit, but one or more good\ncommits, so tweak the man page in a few places to make that clear.\n\nrday\n\nSigned-off-by: Robert P. J. Day <rpjday@crashcourse.ca>\n\n---\n\n  i also exercised literary license to reword an example to look for a\ncommit where performance was *degraded* rather than improved, since i\nthink that's the sort of thing that people would be more interested\nin.\n\n  also tried to keep line lengths consistent.\n\ndiff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt\nindex 6c42abf07..545098e73 100644\n--- a/Documentation/git-bisect.txt\n+++ b/Documentation/git-bisect.txt\n@@ -30,17 +30,17 @@ on the subcommand:\n  git bisect help\n\n This command uses a binary search algorithm to find which commit in\n-your project's history introduced a bug. You use it by first telling\n-it a \"bad\" commit that is known to contain the bug, and a \"good\"\n-commit that is known to be before the bug was introduced. Then `git\n-bisect` picks a commit between those two endpoints and asks you\n+your project's history introduced a bug. You use it by first telling it\n+a \"bad\" commit that is known to contain the bug, and one or more \"good\"\n+commits that are known to be before the bug was introduced. Then `git\n+bisect` picks a commit somewhere in between those commits and asks you\n whether the selected commit is \"good\" or \"bad\". It continues narrowing\n down the range until it finds the exact commit that introduced the\n change.\n\n In fact, `git bisect` can be used to find the commit that changed\n *any* property of your project; e.g., the commit that fixed a bug, or\n-the commit that caused a benchmark's performance to improve. To\n+the commit that caused a benchmark's performance to degrade. To\n support this more general usage, the terms \"old\" and \"new\" can be used\n in place of \"good\" and \"bad\", or you can choose your own terms. See\n section \"Alternate terms\" below for more information.\n@@ -58,7 +58,7 @@ $ git bisect bad                 # Current version is bad\n $ git bisect good v2.6.13-rc2    # v2.6.13-rc2 is known to be good\n ------------------------------------------------\n\n-Once you have specified at least one bad and one good commit, `git\n+Once you have specified one bad and one or more good commits, `git\n bisect` selects a commit in the middle of that range of history,\n checks it out, and outputs something similar to the following:\n\n@@ -137,7 +137,7 @@ respectively, in place of \"good\" and \"bad\". (But note that you cannot\n mix \"good\" and \"bad\" with \"old\" and \"new\" in a single session.)\n\n In this more general usage, you provide `git bisect` with a \"new\"\n-commit that has some property and an \"old\" commit that doesn't have that\n+commit with some property and some \"old\" commits that don't have that\n property. Each time `git bisect` checks out a commit, you test if that\n commit has the property. If it does, mark the commit as \"new\";\n otherwise, mark it as \"old\". When the bisection is done, `git bisect`\n@@ -145,19 +145,19 @@ will report which commit introduced the property.\n\n To use \"old\" and \"new\" instead of \"good\" and bad, you must run `git\n bisect start` without commits as argument and then run the following\n-commands to add the commits:\n+commands to identify the commits:\n\n ------------------------------------------------\n-git bisect old [<rev>]\n+git bisect old [<rev>...]\n ------------------------------------------------\n\n-to indicate that a commit was before the sought change, or\n+to identify commits before the sought change, or\n\n ------------------------------------------------\n-git bisect new [<rev>...]\n+git bisect new [<rev>]\n ------------------------------------------------\n\n-to indicate that it was after.\n+to indicate a single commit after that change.\n\n To get a reminder of the currently used terms, use\n\n\n-- \n\n========================================================================\nRobert P. J. Day                                 Ottawa, Ontario, CANADA\n                        http://crashcourse.ca\n\nTwitter:                                       http://twitter.com/rpjday\nLinkedIn:                               http://ca.linkedin.com/in/rpjday\n========================================================================\n"},{"id":"332285","messageId":"20171111134430.GA30635@alpha.vpn.ikke.info","threadId":"47168","inReplyTo":"alpine.LFD.2.21.1711110820370.8941@localhost.localdomain","subject":"Re: [PATCH] bisect: clarify that one can select multiple good commits","fromName":"Kevin Daudt","fromEmail":"me@ikke.info","sentAt":"2017-11-11T13:44:30Z","receivedAt":"2017-11-11T13:44:35Z","isPatch":true,"sender":{"key":"me@ikke.info","avatar":"https://avatars.githubusercontent.com/u/135698?v=4"},"body":"On Sat, Nov 11, 2017 at 08:26:00AM -0500, Robert P. J. Day wrote:\n> \n> Current man page for \"bisect\" is inconsistent explaining the fact that\n> \"git bisect\" takes precisely one bad commit, but one or more good\n> commits, so tweak the man page in a few places to make that clear.\n> \n> rday\n> \n> Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>\n> \n> ---\n> \n>   i also exercised literary license to reword an example to look for a\n> commit where performance was *degraded* rather than improved, since i\n> think that's the sort of thing that people would be more interested\n> in.\n> \n>  In fact, `git bisect` can be used to find the commit that changed\n>  *any* property of your project; e.g., the commit that fixed a bug, or\n> -the commit that caused a benchmark's performance to improve. To\n> +the commit that caused a benchmark's performance to degrade. To\n>  support this more general usage, the terms \"old\" and \"new\" can be used\n>  in place of \"good\" and \"bad\", or you can choose your own terms. See\n>  section \"Alternate terms\" below for more information.\n> @@ -58,7 +58,7 @@ $ git bisect bad                 # Current version is bad\n>  $ git bisect good v2.6.13-rc2    # v2.6.13-rc2 is known to be good\n>  ------------------------------------------------\n> \n\nI think this example was meant to suggest that it's not only possible to\nfind bad things (bugs, performance degradations), but also the opposite\n(when was a bug fixed, what caused the performance to change). \n\nSo I think it's good to keep the example like it is.\n"},{"id":"332286","messageId":"alpine.LFD.2.21.1711110846001.9944@localhost.localdomain","threadId":"47168","inReplyTo":"20171111134430.GA30635@alpha.vpn.ikke.info","subject":"Re: [PATCH] bisect: clarify that one can select multiple good commits","fromName":"Robert P. J. Day","fromEmail":"rpjday@crashcourse.ca","sentAt":"2017-11-11T13:46:26Z","receivedAt":"2017-11-11T13:46:55Z","isPatch":true,"sender":{"key":"rpjday@crashcourse.ca","avatar":"https://avatars.githubusercontent.com/u/226084077?v=4"},"body":"On Sat, 11 Nov 2017, Kevin Daudt wrote:\n\n> On Sat, Nov 11, 2017 at 08:26:00AM -0500, Robert P. J. Day wrote:\n> >\n> > Current man page for \"bisect\" is inconsistent explaining the fact that\n> > \"git bisect\" takes precisely one bad commit, but one or more good\n> > commits, so tweak the man page in a few places to make that clear.\n> >\n> > rday\n> >\n> > Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>\n> >\n> > ---\n> >\n> >   i also exercised literary license to reword an example to look for a\n> > commit where performance was *degraded* rather than improved, since i\n> > think that's the sort of thing that people would be more interested\n> > in.\n> >\n> >  In fact, `git bisect` can be used to find the commit that changed\n> >  *any* property of your project; e.g., the commit that fixed a bug, or\n> > -the commit that caused a benchmark's performance to improve. To\n> > +the commit that caused a benchmark's performance to degrade. To\n> >  support this more general usage, the terms \"old\" and \"new\" can be used\n> >  in place of \"good\" and \"bad\", or you can choose your own terms. See\n> >  section \"Alternate terms\" below for more information.\n> > @@ -58,7 +58,7 @@ $ git bisect bad                 # Current version is bad\n> >  $ git bisect good v2.6.13-rc2    # v2.6.13-rc2 is known to be good\n> >  ------------------------------------------------\n> >\n>\n> I think this example was meant to suggest that it's not only possible to\n> find bad things (bugs, performance degradations), but also the opposite\n> (when was a bug fixed, what caused the performance to change).\n>\n> So I think it's good to keep the example like it is.\n\n  ok, anyone else have any strong opinions on the subject?\n\nrday\n\n-- \n\n========================================================================\nRobert P. J. Day                                 Ottawa, Ontario, CANADA\n                        http://crashcourse.ca\n\nTwitter:                                       http://twitter.com/rpjday\nLinkedIn:                               http://ca.linkedin.com/in/rpjday\n========================================================================\n"}]}