{"thread":{"id":"21477","subject":"[RFC/PATCH 3/3] bisect: simplify calling visualizer using '--bisect-refs'","startedAt":"2009-11-04T04:00:00Z","lastAt":"2009-11-05T05:22:27Z","messageCount":11,"participants":["Christian Couder","Junio C Hamano","Linus Torvalds"],"isPatch":true,"patchVersion":1,"patchTotal":3},"messages":[{"id":"126712","messageId":"20091104034312.4545.2176.chriscool@tuxfamily.org","threadId":"21477","inReplyTo":null,"subject":"[RFC/PATCH 0/3] use '--bisect-refs' as bisect rev machinery option","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2009-11-04T04:00:00Z","receivedAt":"2009-11-04T04:00:00Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"So I suggest to use '--bisect-refs' instead of '--bisect' as the new\nbisect revision machinery option, because otherwise I think we get a\nregression when we call \"git rev-list --bisect BAD --not GOOD\" and we\nare already bisecting with bisect refs different than BAD and GOOD.\nThis also simplifies the code a little bit.\n\nI had a look at using '--bisect-refs' in the git bisect helper instead\nof collecting the good and bad refs in bisect.c::read_bisect_refs(),\nbut I gave up because I think we need the good and bad refs anyway for\nother purposes like checking that all good refs are ancestor of the bad\nref. So I think we would not gain much if anything there.\n\nIf this is ok then the next steps I can do is add some documentation\nand tests for the new '--bisect-refs' option.\n\nChristian Couder (3):\n  t6030: show \"rev-list --bisect\" breakage when bisecting\n  revision: change '--bisect' rev machinery argument to 'bisect-refs'\n  bisect: simplify calling visualizer using '--bisect-refs'\n\n builtin-rev-list.c          |    2 --\n builtin-rev-parse.c         |    4 ++--\n git-bisect.sh               |    3 +--\n revision.c                  |    5 ++---\n revision.h                  |    1 -\n t/t6030-bisect-porcelain.sh |   13 +++++++++++++\n 6 files changed, 18 insertions(+), 10 deletions(-)\n"},{"id":"126713","messageId":"20091104040004.4545.36317.chriscool@tuxfamily.org","threadId":"21477","inReplyTo":"20091104034312.4545.2176.chriscool@tuxfamily.org","subject":"[RFC/PATCH 1/3] t6030: show \"rev-list --bisect\" breakage when bisecting","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2009-11-04T04:00:01Z","receivedAt":"2009-11-04T04:00:01Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"In the following commits:\n\nad3f9a7 Add '--bisect' revision machinery argument\n81ee52b Merge branch 'lt/revision-bisect' into next\n\nthe '--bisect' argument was added to the revision machinery to easily\nuse the \"bad\" and \"good\" refs from the current bisection in any\ncommand that expect some refs.\n\nThe problem was that '--bisect' already had a special meaning for\n\"git rev-list\" outside the revision machinery and now it was eaten by\nthe revision machinery. So a flag named \"bisect\" was added to\n\"struct rev_info\" in these commits, so that \"git rev-list\" outside the\nrevision machinery could see that \"--bisect\" had been used and operate\nas if \"--bisect\" had been passed to it.\n\nBut the above does not fix everything, and this commit adds a test\ncase to show that.\n\nNow \"git rev-list --bisect BAD --not GOOD\" behaves differently\ndepending on whether we are currently bisecting or not. If we are not\ncurrently bisecting, it uses \"BAD --not GOOD\" as the bisect refs and\nif we are bisecting it uses the bisect refs of the current bisection\nas the bisect refs. This means that we don't behave like we used to\nwhen we are bisecting and the reafs passed on the command line to\n\"git rev-list --bisect\" are different from the bisect refs of the\ncurrent bisection.\n\nThe following commit will fix this regression.\n\nSigned-off-by: Christian Couder <chriscool@tuxfamily.org>\n---\n t/t6030-bisect-porcelain.sh |   13 +++++++++++++\n 1 files changed, 13 insertions(+), 0 deletions(-)\n\ndiff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh\nindex def397c..88a2877 100755\n--- a/t/t6030-bisect-porcelain.sh\n+++ b/t/t6030-bisect-porcelain.sh\n@@ -392,6 +392,19 @@ test_expect_success 'bisect does not create a \"bisect\" branch' '\n \tgit branch -D bisect\n '\n \n+test_expect_failure 'bisect and \"rev-list --bisect\"' '\n+\trev_list2=$(git rev-list --bisect $HASH3 --not $HASH1) &&\n+\ttest \"$rev_list2\" = \"$HASH2\" &&\n+\trev_list4=$(git rev-list --bisect $HASH7 --not $HASH1) &&\n+\ttest \"$rev_list4\" = \"$HASH4\" &&\n+\tgit bisect start $HASH7 $HASH1 &&\n+\trev_hash4=$(git rev-parse --verify HEAD) &&\n+\ttest \"$rev_hash4\" = \"$HASH4\" &&\n+\trev_list2=$(git rev-list --bisect $HASH3 --not $HASH1) &&\n+\ttest \"$rev_list2\" = \"$HASH2\" &&\n+\tgit bisect reset\n+'\n+\n # This creates a \"side\" branch to test \"siblings\" cases.\n #\n # H1-H2-H3-H4-H5-H6-H7  <--other\n-- \n1.6.5.1.gaf97d\n"},{"id":"126714","messageId":"20091104040004.4545.49960.chriscool@tuxfamily.org","threadId":"21477","inReplyTo":"20091104034312.4545.2176.chriscool@tuxfamily.org","subject":"[RFC/PATCH 2/3] revision: change '--bisect' rev machinery argument to 'bisect-refs'","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2009-11-04T04:00:02Z","receivedAt":"2009-11-04T04:00:02Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Using '--bisect' as a revision machinery argument is bogus because\nit conflicts with the special '--bisect' argument for \"rev-list\".\nAnd as shown by a test case added by a previous commit, this cannot\nbe fixed by adding a special flag to \"struct rev_info\".\n\nSo this commit just renames the '--bisect' flag to the revision\nmachinery into '--bisect-refs', and reverts the changes that added\nthe special flag to \"struct rev_info\".\n\nThis makes the test case added previously pass.\n\nSigned-off-by: Christian Couder <chriscool@tuxfamily.org>\n---\n builtin-rev-list.c          |    2 --\n builtin-rev-parse.c         |    4 ++--\n revision.c                  |    5 ++---\n revision.h                  |    1 -\n t/t6030-bisect-porcelain.sh |    2 +-\n 5 files changed, 5 insertions(+), 9 deletions(-)\n\ndiff --git a/builtin-rev-list.c b/builtin-rev-list.c\nindex 9e736b4..2ccbfbb 100644\n--- a/builtin-rev-list.c\n+++ b/builtin-rev-list.c\n@@ -320,8 +320,6 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)\n \n \tmemset(&info, 0, sizeof(info));\n \tinfo.revs = &revs;\n-\tif (revs.bisect)\n-\t\tbisect_list = 1;\n \n \tquiet = DIFF_OPT_TST(&revs.diffopt, QUICK);\n \tfor (i = 1 ; i < argc; i++) {\ndiff --git a/builtin-rev-parse.c b/builtin-rev-parse.c\nindex 9526aaf..201a458 100644\n--- a/builtin-rev-parse.c\n+++ b/builtin-rev-parse.c\n@@ -39,7 +39,7 @@ static int is_rev_argument(const char *arg)\n {\n \tstatic const char *rev_args[] = {\n \t\t\"--all\",\n-\t\t\"--bisect\",\n+\t\t\"--bisect-refs\",\n \t\t\"--dense\",\n \t\t\"--branches\",\n \t\t\"--header\",\n@@ -554,7 +554,7 @@ int cmd_rev_parse(int argc, const char **argv, const char *prefix)\n \t\t\t\tfor_each_ref(show_reference, NULL);\n \t\t\t\tcontinue;\n \t\t\t}\n-\t\t\tif (!strcmp(arg, \"--bisect\")) {\n+\t\t\tif (!strcmp(arg, \"--bisect-refs\")) {\n \t\t\t\tfor_each_ref_in(\"refs/bisect/bad\", show_reference, NULL);\n \t\t\t\tfor_each_ref_in(\"refs/bisect/good\", anti_reference, NULL);\n \t\t\t\tcontinue;\ndiff --git a/revision.c b/revision.c\nindex 5cedd15..d1a1edc 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -995,7 +995,7 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg\n \t    !strcmp(arg, \"--tags\") || !strcmp(arg, \"--remotes\") ||\n \t    !strcmp(arg, \"--reflog\") || !strcmp(arg, \"--not\") ||\n \t    !strcmp(arg, \"--no-walk\") || !strcmp(arg, \"--do-walk\") ||\n-\t    !strcmp(arg, \"--bisect\"))\n+\t    !strcmp(arg, \"--bisect-refs\"))\n \t{\n \t\tunkv[(*unkc)++] = arg;\n \t\treturn 1;\n@@ -1270,10 +1270,9 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch\n \t\t\t\thandle_refs(revs, flags, for_each_branch_ref);\n \t\t\t\tcontinue;\n \t\t\t}\n-\t\t\tif (!strcmp(arg, \"--bisect\")) {\n+\t\t\tif (!strcmp(arg, \"--bisect-refs\")) {\n \t\t\t\thandle_refs(revs, flags, for_each_bad_bisect_ref);\n \t\t\t\thandle_refs(revs, flags ^ UNINTERESTING, for_each_good_bisect_ref);\n-\t\t\t\trevs->bisect = 1;\n \t\t\t\tcontinue;\n \t\t\t}\n \t\t\tif (!strcmp(arg, \"--tags\")) {\ndiff --git a/revision.h b/revision.h\nindex 921656a..b6421a6 100644\n--- a/revision.h\n+++ b/revision.h\n@@ -63,7 +63,6 @@ struct rev_info {\n \t\t\treverse:1,\n \t\t\treverse_output_stage:1,\n \t\t\tcherry_pick:1,\n-\t\t\tbisect:1,\n \t\t\tfirst_parent_only:1;\n \n \t/* Diff flags */\ndiff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh\nindex 88a2877..4e4160e 100755\n--- a/t/t6030-bisect-porcelain.sh\n+++ b/t/t6030-bisect-porcelain.sh\n@@ -392,7 +392,7 @@ test_expect_success 'bisect does not create a \"bisect\" branch' '\n \tgit branch -D bisect\n '\n \n-test_expect_failure 'bisect and \"rev-list --bisect\"' '\n+test_expect_success 'bisect and \"rev-list --bisect\"' '\n \trev_list2=$(git rev-list --bisect $HASH3 --not $HASH1) &&\n \ttest \"$rev_list2\" = \"$HASH2\" &&\n \trev_list4=$(git rev-list --bisect $HASH7 --not $HASH1) &&\n-- \n1.6.5.1.gaf97d\n"},{"id":"126711","messageId":"20091104040004.4545.72084.chriscool@tuxfamily.org","threadId":"21477","inReplyTo":"20091104034312.4545.2176.chriscool@tuxfamily.org","subject":"[RFC/PATCH 3/3] bisect: simplify calling visualizer using '--bisect-refs'","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2009-11-04T04:00:03Z","receivedAt":"2009-11-04T04:00:03Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"It is now shorter and safer to use the new '--bisect-refs' revision\nmachinery option, than to compute the refs that we must pass.\n\nSigned-off-by: Christian Couder <chriscool@tuxfamily.org>\n---\n git-bisect.sh |    3 +--\n 1 files changed, 1 insertions(+), 2 deletions(-)\n\ndiff --git a/git-bisect.sh b/git-bisect.sh\nindex 8b3c585..41b9118 100755\n--- a/git-bisect.sh\n+++ b/git-bisect.sh\n@@ -300,8 +300,7 @@ bisect_visualize() {\n \t\tesac\n \tfi\n \n-\tnot=$(git for-each-ref --format='%(refname)' \"refs/bisect/good-*\")\n-\teval '\"$@\"' refs/bisect/bad --not $not -- $(cat \"$GIT_DIR/BISECT_NAMES\")\n+\teval '\"$@\"' --bisect-refs -- $(cat \"$GIT_DIR/BISECT_NAMES\")\n }\n \n bisect_reset() {\n-- \n1.6.5.1.gaf97d\n"},{"id":"126790","messageId":"7vljimgnaz.fsf@alter.siamese.dyndns.org","threadId":"21477","inReplyTo":"20091104034312.4545.2176.chriscool@tuxfamily.org","subject":"Re: [RFC/PATCH 0/3] use '--bisect-refs' as bisect rev machinery option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-04T18:25:08Z","receivedAt":"2009-11-04T18:25:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Christian Couder <chriscool@tuxfamily.org> writes:\n\n> So I suggest to use '--bisect-refs' instead of '--bisect' as the new\n> bisect revision machinery option, because otherwise I think we get a\n> regression when we call \"git rev-list --bisect BAD --not GOOD\" and we\n> are already bisecting with bisect refs different than BAD and GOOD.\n> This also simplifies the code a little bit.\n\nJust to make sure that I read you correctly, do you mean that Linus now\nwould say:\n\n    $ git bisect ...\n    ... inside bisect session\n    $ gitk --bisect-refs arch/x86\n"},{"id":"126791","messageId":"alpine.LFD.2.01.0911041030080.31845@localhost.localdomain","threadId":"21477","inReplyTo":"7vljimgnaz.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH 0/3] use '--bisect-refs' as bisect rev machinery option","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2009-11-04T18:32:53Z","receivedAt":"2009-11-04T18:32:53Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 4 Nov 2009, Junio C Hamano wrote:\n\n> Christian Couder <chriscool@tuxfamily.org> writes:\n> \n> > So I suggest to use '--bisect-refs' instead of '--bisect' as the new\n> > bisect revision machinery option, because otherwise I think we get a\n> > regression when we call \"git rev-list --bisect BAD --not GOOD\" and we\n> > are already bisecting with bisect refs different than BAD and GOOD.\n> > This also simplifies the code a little bit.\n> \n> Just to make sure that I read you correctly, do you mean that Linus now\n> would say:\n> \n>     $ git bisect ...\n>     ... inside bisect session\n>     $ gitk --bisect-refs arch/x86\n\nI'd really rather prefer to keep '--bisect' for that, it doesn't make \nsense to export '--bisect-refs' to be the user-visible switch, and then \nhave '--bisect' as some internal switch just for 'git rev-list'.\n\nIn fact, I'd argue that the ne wbehavior of 'git rev-list' is to some \ndegree _better_ (ie the existing bad/good ones are implicit while doing \nbisection).\n\nYes, it is a behavioral change, but is it a bad one?\n\n\t\t\tLinus\n"},{"id":"126792","messageId":"alpine.LFD.2.01.0911041033530.31845@localhost.localdomain","threadId":"21477","inReplyTo":"alpine.LFD.2.01.0911041030080.31845@localhost.localdomain","subject":"Re: [RFC/PATCH 0/3] use '--bisect-refs' as bisect rev machinery option","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2009-11-04T18:35:47Z","receivedAt":"2009-11-04T18:35:47Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 4 Nov 2009, Linus Torvalds wrote:\n> \n> Yes, it is a behavioral change, but is it a bad one?\n\n.. and perhaps we could introduce --bisect-refs as the \"old behavior\" of \n'--bisect' to git rev-list?\n\nI kind of suspect that it is unlikely that people are using 'git rev-list \n--bisect' while _inside_ a bisection, but then wanting to bisect someting \nthat is outside the set of commits we're currently actively bisecting.\n\nBut maybe I'm wrong.\n\n\t\tLinus\n"},{"id":"126796","messageId":"7veioegko3.fsf@alter.siamese.dyndns.org","threadId":"21477","inReplyTo":"alpine.LFD.2.01.0911041033530.31845@localhost.localdomain","subject":"Re: [RFC/PATCH 0/3] use '--bisect-refs' as bisect rev machinery option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-04T19:22:04Z","receivedAt":"2009-11-04T19:22:04Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@linux-foundation.org> writes:\n\n> On Wed, 4 Nov 2009, Linus Torvalds wrote:\n>> \n>> Yes, it is a behavioral change, but is it a bad one?\n>\n> .. and perhaps we could introduce --bisect-refs as the \"old behavior\" of \n> '--bisect' to git rev-list?\n>\n> I kind of suspect that it is unlikely that people are using 'git rev-list \n> --bisect' while _inside_ a bisection, but then wanting to bisect someting \n> that is outside the set of commits we're currently actively bisecting.\n>\n> But maybe I'm wrong.\n\nMaybe I'm wrong too, but I do not think that is plausible that people are\ndoing nested bisection that way.  It is probably a useful thing to do, but\nif somebody has thought of doing so we would have at least seen a request\nto add a way to tell \"git-bisect\" what names to use to record the good/bad\nset of commits under to make their implementation easier.  I haven't, and\nI take it an indication that it is very implausible that such scripts by\npeople exist to be broken by this change.\n\nI was more worried about people who reinvented the wheel and are using\ntheir own git-bisect.sh derivative.  It probably was forked from the\nversion that still used 'git rev-list --bisect\", manually feeding good and\nbad set of commits to it from the command line.  But then what they are\nfeeding would be the same as the new --bisect option implicitly gives them\nanyway, so there won't be a regression either.\n"},{"id":"126830","messageId":"200911042226.25599.chriscool@tuxfamily.org","threadId":"21477","inReplyTo":"7veioegko3.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH 0/3] use '--bisect-refs' as bisect rev machinery option","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2009-11-04T21:26:25Z","receivedAt":"2009-11-04T21:26:25Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Wednesday 04 November 2009, Junio C Hamano wrote:\n> Linus Torvalds <torvalds@linux-foundation.org> writes:\n> > On Wed, 4 Nov 2009, Linus Torvalds wrote:\n> >> Yes, it is a behavioral change, but is it a bad one?\n> >\n> > .. and perhaps we could introduce --bisect-refs as the \"old behavior\"\n> > of '--bisect' to git rev-list?\n> >\n> > I kind of suspect that it is unlikely that people are using 'git\n> > rev-list --bisect' while _inside_ a bisection, but then wanting to\n> > bisect someting that is outside the set of commits we're currently\n> > actively bisecting.\n> >\n> > But maybe I'm wrong.\n>\n> Maybe I'm wrong too, but I do not think that is plausible that people are\n> doing nested bisection that way.  It is probably a useful thing to do,\n> but if somebody has thought of doing so we would have at least seen a\n> request to add a way to tell \"git-bisect\" what names to use to record the\n> good/bad set of commits under to make their implementation easier.  I\n> haven't, and I take it an indication that it is very implausible that\n> such scripts by people exist to be broken by this change.\n>\n> I was more worried about people who reinvented the wheel and are using\n> their own git-bisect.sh derivative.  It probably was forked from the\n> version that still used 'git rev-list --bisect\", manually feeding good\n> and bad set of commits to it from the command line.  But then what they\n> are feeding would be the same as the new --bisect option implicitly gives\n> them anyway, so there won't be a regression either.\n\nI don't remember exactly when, but at one time some people talked about \nparallelizing bisection. The idea was that if it takes a long time to test \none commit but you can test many commits at the same time (for example on \ndifferent machines), then you can bisect faster by testing at the same time \nthe current commit that git bisect checked out for you and for example the \ncommit that git bisect would give you if the current commit is bad and the \ncommit it would give you if the current commit is good.\n\nSo to do that you would use \"git bisect start ...\" and then you could use:\n\n$ git rev-list --bisect HEAD --not $GOOD_COMMITS\n\nto get the commit that you would have to test if the current commit is bad \nand:\n\n$ git rev-list --bisect  $BAD --not $GOOD_COMMITS HEAD\n\nto get the commit that you would have to test if the current commit is good.\n\nOk, perhaps nobody is doing that.\n\nAnd yes I agree that it would be probably better to have --bisect be the \nname of the revision machinery option and --bisect-refs or perhaps another \nname like --bisect-compute be the name of the special option to \"git \nrev-list\".\n\nBut perhaps we can introduce --bisect-compute to do the same thing \nthat --bisect currently does and deprecate --bisect with a warning and then \na few versions later remove it and after a few more versions \nintroduce --bisect to do the same as --bisect-refs.\n\nBest regards,\nChristian.\n"},{"id":"126837","messageId":"7vtyxaez4f.fsf@alter.siamese.dyndns.org","threadId":"21477","inReplyTo":"200911042226.25599.chriscool@tuxfamily.org","subject":"Re: [RFC/PATCH 0/3] use '--bisect-refs' as bisect rev machinery option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-04T21:52:48Z","receivedAt":"2009-11-04T21:52:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Christian Couder <chriscool@tuxfamily.org> writes:\n\n> So to do that you would use \"git bisect start ...\" and then you could use:\n>\n> $ git rev-list --bisect HEAD --not $GOOD_COMMITS\n>\n> to get the commit that you would have to test if the current commit is bad \n> and:\n>\n> $ git rev-list --bisect  $BAD --not $GOOD_COMMITS HEAD\n>\n> to get the commit that you would have to test if the current commit is good.\n\nEven in that case, the problem is still about narrowing the set of the\ncurrent bisection graph.  If --bisect option implicitly grabs good and bad\ndefined in the refspace like Linus's patch does, it will give you the same\nbehaviour of the above two commands, no?\n"},{"id":"126874","messageId":"200911050622.27159.chriscool@tuxfamily.org","threadId":"21477","inReplyTo":"7vtyxaez4f.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH 0/3] use '--bisect-refs' as bisect rev machinery option","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2009-11-05T05:22:27Z","receivedAt":"2009-11-05T05:22:27Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Wednesday 04 November 2009, Junio C Hamano wrote:\n> Christian Couder <chriscool@tuxfamily.org> writes:\n> > So to do that you would use \"git bisect start ...\" and then you could\n> > use:\n> >\n> > $ git rev-list --bisect HEAD --not $GOOD_COMMITS\n> >\n> > to get the commit that you would have to test if the current commit is\n> > bad and:\n> >\n> > $ git rev-list --bisect  $BAD --not $GOOD_COMMITS HEAD\n> >\n> > to get the commit that you would have to test if the current commit is\n> > good.\n>\n> Even in that case, the problem is still about narrowing the set of the\n> current bisection graph.  If --bisect option implicitly grabs good and\n> bad defined in the refspace like Linus's patch does, it will give you the\n> same behaviour of the above two commands, no?\n\nI think it will probably work when you add a good rev, but in the case where \nyou give a different bad (the first command above) it does not work the \nsame.\n\nThe test case in patch 1/3 shows that. It does:\n\ngit bisect start $HASH7 $HASH1 &&\n...\nrev_list2=$(git rev-list --bisect $HASH3 --not $HASH1) &&\ntest \"$rev_list2\" = \"$HASH2\" \n\nand that last command fails.\n\nBest regards,\nChristian.\n"}]}