{"thread":{"id":"14233","subject":"[PATCH] bisect: error out when given any good rev that is not an ancestor of the bad rev","startedAt":"2008-06-30T22:42:11Z","lastAt":"2008-07-01T01:13:16Z","messageCount":11,"participants":["Christian Couder","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"81789","messageId":"20080701004211.ba9b89c9.chriscool@tuxfamily.org","threadId":"14233","inReplyTo":null,"subject":"[PATCH] bisect: error out when given any good rev that is not an ancestor of the bad rev","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2008-06-30T22:42:11Z","receivedAt":"2008-06-30T22:42:11Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Before this patch \"git bisect\" doesn't really work when it is given\nsome good revs that are siblings of the bad rev.\n\nFor example if there is the following history:\n\nA-B-C-D\n   \\E-F\n\nand we launch \"git bisect start D F\" then only C and D will be\nconsidered as possible first bad commit. This is wrong because A, B and\nE may be bad too if the bug exists everywhere except in F that fixes it.\n\nMaybe there is a way to make the above work, but for now the purpose of\nthis patch is to fix the problem by checking that all good revs are\nancestor of the bad rev and by erroring out if this is not the case.\n\nTo do that we run \"git rev-list ^bad good\" and we check that it outputs\nnothing.\n\nThis check will also catch the case where good and bad have been\nmistaken. This means that we can remove the check that was done latter\non the output of \"git rev-list --bisect-vars\". The downside of that is\nthat now we can't tell between a mistake and a \"siblings\" case.\n\nSigned-off-by: Christian Couder <chriscool@tuxfamily.org>\n---\n git-bisect.sh               |   32 +++++++++++++++-----------------\n t/t6030-bisect-porcelain.sh |   19 +++++++++++++++++++\n 2 files changed, 34 insertions(+), 17 deletions(-)\n\n\tMaybe we can improve on this patch by trying to tell between\n\ta mistake and a \"siblings\" case to give a better error\n\tmessage.\n\ndiff --git a/git-bisect.sh b/git-bisect.sh\nindex 991b2ef..90a9d74 100755\n--- a/git-bisect.sh\n+++ b/git-bisect.sh\n@@ -242,33 +242,18 @@ bisect_auto_next() {\n \tbisect_next_check && bisect_next || :\n }\n \n-eval_rev_list() {\n-\t_eval=\"$1\"\n-\n-\teval $_eval\n-\tres=$?\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\texit $res\n-\tfi\n-\n-\treturn $res\n-}\n-\n filter_skipped() {\n \t_eval=\"$1\"\n \t_skip=\"$2\"\n \n \tif [ -z \"$_skip\" ]; then\n-\t\teval_rev_list \"$_eval\"\n+\t\teval \"$_eval\"\n \t\treturn\n \tfi\n \n \t# Let's parse the output of:\n \t# \"git rev-list --bisect-vars --bisect-all ...\"\n-\teval_rev_list \"$_eval\" | while read hash line\n+\teval \"$_eval\" | while read hash line\n \tdo\n \t\tcase \"$VARS,$FOUND,$TRIED,$hash\" in\n \t\t\t# We display some vars.\n@@ -331,6 +316,18 @@ exit_if_skipped_commits () {\n \tfi\n }\n \n+check_good_are_ancestor_of_bad() {\n+\t_bad=\"^$1\"\n+\t_good=$(echo $2 | sed -e 's/\\^//g')\n+\t_side=$(git rev-list $_good $_bad)\n+\tif test -n \"$_side\"; then\n+\t\techo >&2 \"Some good revs are not ancestor of the bad rev.\"\n+\t\techo >&2 \"git bisect cannot work properly in this case.\"\n+\t\techo >&2 \"Maybe you mistake good and bad revs?\"\n+\t\treturn 1\n+\tfi\n+}\n+\n bisect_next() {\n \tcase \"$#\" in 0) ;; *) usage ;; esac\n \tbisect_autostart\n@@ -345,6 +342,7 @@ bisect_next() {\n \tbad=$(git rev-parse --verify refs/bisect/bad) &&\n \tgood=$(git for-each-ref --format='^%(objectname)' \\\n \t\t\"refs/bisect/good-*\" | tr '\\012' ' ') &&\n+\tcheck_good_are_ancestor_of_bad \"$bad\" \"$good\" &&\n \teval=\"git rev-list --bisect-vars $BISECT_OPT $good $bad --\" &&\n \teval=\"$eval $(cat \"$GIT_DIR/BISECT_NAMES\")\" &&\n \teval=$(filter_skipped \"$eval\" \"$skip\") &&\ndiff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh\nindex 0626544..b3f3869 100755\n--- a/t/t6030-bisect-porcelain.sh\n+++ b/t/t6030-bisect-porcelain.sh\n@@ -350,6 +350,25 @@ test_expect_success 'bisect does not create a \"bisect\" branch' '\n \tgit branch -D bisect\n '\n \n+# This creates a \"side\" branch to test \"siblings\" cases.\n+test_expect_success 'bisect errors out when good and bad are siblings' '\n+\tgit bisect reset &&\n+\tgit checkout -b side $HASH4 &&\n+\tadd_line_into_file \"5(side): first line on a side branch\" hello &&\n+\tSIDE_HASH5=$(git rev-parse --verify HEAD) &&\n+\tadd_line_into_file \"6(side): second line on a side branch\" hello &&\n+\tSIDE_HASH6=$(git rev-parse --verify HEAD) &&\n+\tadd_line_into_file \"7(side): third line on a side branch\" hello &&\n+\tSIDE_HASH7=$(git rev-parse --verify HEAD) &&\n+\ttest_must_fail git bisect start \"$HASH7\" \"$SIDE_HASH7\" &&\n+\ttest_must_fail git bisect start \"$SIDE_HASH7\" \"$HASH7\" &&\n+\ttest_must_fail git bisect start \"$HASH7\" HEAD &&\n+\ttest_must_fail git bisect start \"$SIDE_HASH5\" \"$HASH7\" &&\n+\ttest_must_fail test -e .git/BISECT_START &&\n+\ttest -z \"$(git for-each-ref \"refs/bisect/*\")\" &&\n+\ttest \"$(git rev-parse --verify HEAD)\" = \"$SIDE_HASH7\"\n+'\n+\n #\n #\n test_done\n-- \n1.5.6.7.g5b8fa.dirty\n"},{"id":"81791","messageId":"7v3amuv8yg.fsf@gitster.siamese.dyndns.org","threadId":"14233","inReplyTo":"20080701004211.ba9b89c9.chriscool@tuxfamily.org","subject":"Re: [PATCH] bisect: error out when given any good rev that is not an ancestor of the bad rev","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-30T22:44:55Z","receivedAt":"2008-06-30T22:44:55Z","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> Before this patch \"git bisect\" doesn't really work when it is given\n> some good revs that are siblings of the bad rev.\n>\n> For example if there is the following history:\n>\n> A-B-C-D\n>    \\E-F\n>\n> and we launch \"git bisect start D F\" then only C and D will be\n> considered as possible first bad commit. This is wrong because A, B and\n> E may be bad too if the bug exists everywhere except in F that fixes it.\n\nPlease don't.\n\nbisect is about finding a single regression by partitioning the graph into\nolder good section and newer bad section with a *single* \"first bad\ncommit\".\n\nFor your \"this could also be possible\" scenario is already outside the\nrealm.  You are assuming A, B and F is good, and D is bad.  But if E is\nbad, then that breakage cannot possibly affect the transition between B\nand D from good to bad (E cannot break D), so C must *also* be bad.\n"},{"id":"81793","messageId":"7vy74mtu7i.fsf@gitster.siamese.dyndns.org","threadId":"14233","inReplyTo":"7v3amuv8yg.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] bisect: error out when given any good rev that is not an ancestor of the bad rev","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-30T22:48:49Z","receivedAt":"2008-06-30T22:48:49Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Christian Couder <chriscool@tuxfamily.org> writes:\n>\n>> Before this patch \"git bisect\" doesn't really work when it is given\n>> some good revs that are siblings of the bad rev.\n>>\n>> For example if there is the following history:\n>>\n>> A-B-C-D\n>>    \\E-F\n>>\n>> and we launch \"git bisect start D F\" then only C and D will be\n>> considered as possible first bad commit. This is wrong because A, B and\n>> E may be bad too if the bug exists everywhere except in F that fixes it.\n>\n> Please don't.\n>\n> bisect is about finding a single regression by partitioning the graph into\n> older good section and newer bad section with a *single* \"first bad\n> commit\".\n>\n> Your \"this could also be possible\" scenario is already outside the\n> realm.  You are assuming A, B and F is good, and D is bad.  But if E is\n> bad, then that breakage cannot possibly affect the transition between B\n> and D from good to bad (E cannot break D), so C must *also* be bad.\n\n... which means you are dealing with *two* breakages.  That's outside what\nbisect deals with.\n\nAnd this does not need to have forked development.  If the graph were like\nthis:\n\n  A-B-C-D-E-F\n\nand if F is bad and B is good, with your logic, after checking that D is\nalready bad, we cannot discount E --- after somehow fixing D, we _might_\nalso be introducing another breakage with E.  You cannot even check for\nthat anyway, but the logic is the same.\n"},{"id":"81801","messageId":"200807010116.30214.chriscool@tuxfamily.org","threadId":"14233","inReplyTo":"7v3amuv8yg.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] bisect: error out when given any good rev that is not an ancestor of the bad rev","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2008-06-30T23:16:30Z","receivedAt":"2008-06-30T23:16:30Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Le mardi 1 juillet 2008, Junio C Hamano a écrit :\n> Christian Couder <chriscool@tuxfamily.org> writes:\n> > Before this patch \"git bisect\" doesn't really work when it is given\n> > some good revs that are siblings of the bad rev.\n> >\n> > For example if there is the following history:\n> >\n> > A-B-C-D\n> >    \\E-F\n> >\n> > and we launch \"git bisect start D F\" then only C and D will be\n> > considered as possible first bad commit. This is wrong because A, B and\n> > E may be bad too if the bug exists everywhere except in F that fixes\n> > it.\n>\n> Please don't.\n>\n> bisect is about finding a single regression by partitioning the graph\n> into older good section and newer bad section with a *single* \"first bad\n> commit\".\n>\n> For your \"this could also be possible\" scenario is already outside the\n> realm.  You are assuming A, B and F is good, and D is bad.\n\nI am assuming the first bad commit in the graph is A and it is fixed by F.\n\n> But if E is \n> bad, then that breakage cannot possibly affect the transition between B\n> and D from good to bad (E cannot break D), so C must *also* be bad.\n\nYes, I assume C is also bad.\n\n> ... which means you are dealing with *two* breakages.  That's outside\n> what bisect deals with.\n\nSorry, I don't understand why I am assuming 2 breakages.\n\n> And this does not need to have forked development.  If the graph were\n> like this:\n>\n>   A-B-C-D-E-F\n>\n> and if F is bad and B is good, with your logic, after checking that D is\n> already bad, we cannot discount E --- after somehow fixing D, we _might_\n> also be introducing another breakage with E.  You cannot even check for\n> that anyway, but the logic is the same.\n\nI don't think the logic is the same because in your case git bisect will \nreport one first bad commit anyway even if this bad commit has been fixed \nlatter.\n\nIn my case above, git bisect currently considers C and D as the only \npossible bad commits because when it is told that F is good, it assumes \nthat all the ancestors or F are good too. And this means that B is \nconsidered good so C will be found as the first bad commit. I think this \ncan be really misleading because there is no good->bad transition between B \nand C.\n\nRegards,\nChristian.\n"},{"id":"81803","messageId":"7vtzfatsf4.fsf@gitster.siamese.dyndns.org","threadId":"14233","inReplyTo":"200807010116.30214.chriscool@tuxfamily.org","subject":"Re: [PATCH] bisect: error out when given any good rev that is not an ancestor of the bad rev","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-30T23:27:27Z","receivedAt":"2008-06-30T23:27:27Z","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> Yes, I assume C is also bad.\n>\n>> ... which means you are dealing with *two* breakages.  That's outside\n>> what bisect deals with.\n>\n> Sorry, I don't understand why I am assuming 2 breakages.\n\nYour topology is\n\n>> > A-B-C-D\n>> >    \\E-F\n\nand you start with \"D F\" so D is bad and F is good, right?\n\nbisect operates on a history with a single breakage that separates older\ngood ones and newer bad ones.\n\nNow D is bad, so there must be somewhere in\n\n\tA--B--C--D\n\nthat broke D.  It could be D itself, or it may have been broken at A\nalready.\n\nBut if A or B were bad, then, because F is good, this part of the picture:\n\n\tA--B--E--F\n\ndoes not deal with \"old good followed by new bad sparated by a single\nbreakage point\".  Maybe E or F have fixed it, but then before that is bad\nand after that is good.  That's not what bisect deals with.\n\nGoing back to the original picture, then:\n\n>> > A-B-C-D\n>> >    \\E-F\n\nFor F to be good, all of its ancestors are by definition good (that is the\nbasic assumption of bisection).  A and B are good.  If D is broken, C or D\nmust be broken.\n\nSo we do not decend into B nor its ancestor.\n\nThe logic is the same if the history is linear.\n\n\tA--B--C--D--E--F\n\nIf B is good and F is bad, and if you check D and find out that D is still\ngood, then we can ignore everything behind D, and that is what lets us\nlimit the search space and suspect only E or F.  This is exactly the same\n\"Everything that leads to a good one is good\" principle upon which\nbisection works.\n"},{"id":"81804","messageId":"7vprpyts7j.fsf@gitster.siamese.dyndns.org","threadId":"14233","inReplyTo":"200807010116.30214.chriscool@tuxfamily.org","subject":"Re: [PATCH] bisect: error out when given any good rev that is not an ancestor of the bad rev","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-30T23:32:00Z","receivedAt":"2008-06-30T23:32:00Z","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> Le mardi 1 juillet 2008, Junio C Hamano a écrit :\n>> Christian Couder <chriscool@tuxfamily.org> writes:\n>> > Before this patch \"git bisect\" doesn't really work when it is given\n>> > some good revs that are siblings of the bad rev.\n>> >\n>> > For example if there is the following history:\n>> >\n>> > A-B-C-D\n>> >    \\E-F\n>> >\n>> > and we launch \"git bisect start D F\" then only C and D will be\n>> > considered as possible first bad commit.\n>\n> I am assuming the first bad commit in the graph is A and it is fixed by F.\n\nAh, I see your confusion here.  bisect is about finding regressions.\n\"Older ones were good, and now there is a breakage.  Who broke it?\"\n\nIf F fixed it, that is already outside the bisection's scope.  The user\nneeds to know that by saying F is good, he is saying he knows everything\nthat leads to F is good.\n"},{"id":"81807","messageId":"7vlk0mtrqt.fsf@gitster.siamese.dyndns.org","threadId":"14233","inReplyTo":"7vprpyts7j.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] bisect: error out when given any good rev that is not an ancestor of the bad rev","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-30T23:42:02Z","receivedAt":"2008-06-30T23:42:02Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Christian Couder <chriscool@tuxfamily.org> writes:\n>\n>> Le mardi 1 juillet 2008, Junio C Hamano a écrit :\n>>> Christian Couder <chriscool@tuxfamily.org> writes:\n>>> > Before this patch \"git bisect\" doesn't really work when it is given\n>>> > some good revs that are siblings of the bad rev.\n>>> >\n>>> > For example if there is the following history:\n>>> >\n>>> > A-B-C-D\n>>> >    \\E-F\n>>> >\n>>> > and we launch \"git bisect start D F\" then only C and D will be\n>>> > considered as possible first bad commit.\n>>\n>> I am assuming the first bad commit in the graph is A and it is fixed by F.\n>\n> Ah, I see your confusion here.  bisect is about finding regressions.\n> \"Older ones were good, and now there is a breakage.  Who broke it?\"\n>\n> If F fixed it, that is already outside the bisection's scope.  The user\n> needs to know that by saying F is good, he is saying he knows everything\n> that leads to F is good.\n\nOk, I wasn't thinking straight.\n\nThe tricky part is that the user does not know.\n\nUntil we somehow can check B is bad, we cannot tell that the original\nbisection was done incorrectly (in the sense that it was not finding\nregression, but what the user could find is which commit fixed it).\n\nIf we perform a test merge between D and F and test that tree, and if that\nturns out to be Ok, that would be a good indication of existence of a fix\n(i.e. the topology is not \"old good code was broken somewhere\", but \"old\nbroken code was fixed somewhere\").  I am not sure how applicable that\napproach would be in practice, though.\n"},{"id":"81806","messageId":"200807010146.09206.chriscool@tuxfamily.org","threadId":"14233","inReplyTo":"7vprpyts7j.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] bisect: error out when given any good rev that is not an ancestor of the bad rev","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2008-06-30T23:46:09Z","receivedAt":"2008-06-30T23:46:09Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Le mardi 1 juillet 2008, Junio C Hamano a écrit :\n> Christian Couder <chriscool@tuxfamily.org> writes:\n> > Le mardi 1 juillet 2008, Junio C Hamano a écrit :\n> >> Christian Couder <chriscool@tuxfamily.org> writes:\n> >> > Before this patch \"git bisect\" doesn't really work when it is given\n> >> > some good revs that are siblings of the bad rev.\n> >> >\n> >> > For example if there is the following history:\n> >> >\n> >> > A-B-C-D\n> >> >    \\E-F\n> >> >\n> >> > and we launch \"git bisect start D F\" then only C and D will be\n> >> > considered as possible first bad commit.\n> >\n> > I am assuming the first bad commit in the graph is A and it is fixed by\n> > F.\n>\n> Ah, I see your confusion here.  bisect is about finding regressions.\n> \"Older ones were good, and now there is a breakage.  Who broke it?\"\n>\n> If F fixed it, that is already outside the bisection's scope.  The user\n> needs to know that by saying F is good, he is saying he knows everything\n> that leads to F is good.\n\nYes, but the fact is that the user may wrongly think that F is an ancestor \nof D or he may not remember/know about the rule that saying \"F is good\" \nmeans \"everything from A to F is good\". That's why this patch adds a safety \nnet by detecting end erroring out in this case.\n\nRegards,\nChristian.\n"},{"id":"81810","messageId":"7vej6etra7.fsf@gitster.siamese.dyndns.org","threadId":"14233","inReplyTo":"200807010146.09206.chriscool@tuxfamily.org","subject":"Re: [PATCH] bisect: error out when given any good rev that is not an ancestor of the bad rev","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-30T23:52:00Z","receivedAt":"2008-06-30T23:52:00Z","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> Yes, but the fact is that the user may wrongly think that F is an ancestor \n> of D or he may not remember/know about the rule that saying \"F is good\" \n> means \"everything from A to F is good\". That's why this patch adds a safety \n> net by detecting end erroring out in this case.\n\nYeah, sorry about the confusion earlier.\n\nBut I do not think forbidding forked topology very early in bisection\nprocess is a very good idea.  The user would be at loss when told:\n\n\techo >&2 \"Maybe you mistake good and bad revs?\"\n\nAside from the \"test a trial merge\" idea I floated in the other message,\nwhen we detect such a fork, perhaps we can suggest testing the merge base\nversion (B in your picture) first?  We would immediately know as the user\nwould say \"B is bad\" if the topology is problematic.\n\nThen, we can suggest the user that breakage at D may not be a regression\nbut a longstanding bug that was recently fixed somewhere between B and F.\n\nThe user then can decide to bisect to find the fix (so that it can be\ncherry picked on top of D) or merge F into D to propagate the fix forward\nif it is not important to find out which exact commit fixed the issue.\n\nHmm?\n"},{"id":"81813","messageId":"200807010220.44657.chriscool@tuxfamily.org","threadId":"14233","inReplyTo":"7vej6etra7.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] bisect: error out when given any good rev that is not an ancestor of the bad rev","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2008-07-01T00:20:44Z","receivedAt":"2008-07-01T00:20:44Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Le mardi 1 juillet 2008, Junio C Hamano a écrit :\n> Christian Couder <chriscool@tuxfamily.org> writes:\n> > Yes, but the fact is that the user may wrongly think that F is an\n> > ancestor of D or he may not remember/know about the rule that saying \"F\n> > is good\" means \"everything from A to F is good\". That's why this patch\n> > adds a safety net by detecting end erroring out in this case.\n>\n> Yeah, sorry about the confusion earlier.\n>\n> But I do not think forbidding forked topology very early in bisection\n> process is a very good idea.  The user would be at loss when told:\n>\n> \techo >&2 \"Maybe you mistake good and bad revs?\"\n\nYeah, perhaps we should then check that it can be a mistake by testing if \nbad is an ancestor of good. If bad is indeed an ancestor of good, it's \nprobably a mistake and we may even ask if the user wants good and bad to be \nswaped (assuming he gave only one good rev of course).\n\n> Aside from the \"test a trial merge\" idea I floated in the other message,\n> when we detect such a fork, perhaps we can suggest testing the merge base\n> version (B in your picture) first?  We would immediately know as the user\n> would say \"B is bad\" if the topology is problematic.\n\nYes this can be a good idea, if the user gave only one good rev. It maybe \nmore tricky if he gave many good revs, but in this case we may perhaps drop \nsiblings good revs as long as one good rev is an ancestor of the bad rev.\n\n> Then, we can suggest the user that breakage at D may not be a regression\n> but a longstanding bug that was recently fixed somewhere between B and F.\n>\n> The user then can decide to bisect to find the fix (so that it can be\n> cherry picked on top of D) or merge F into D to propagate the fix forward\n> if it is not important to find out which exact commit fixed the issue.\n>\n> Hmm?\n\nYeah that might be a plan.\n\nAnother option is to introduce a switch to \"git bisect start\", \nperhaps --strict, to please people who always want to use good revs that \nare ancestor of the bad revs, so they get a nice error when this is not the \ncase.\n\nThanks,\nChristian.\n"},{"id":"81815","messageId":"7v7ic6tnir.fsf@gitster.siamese.dyndns.org","threadId":"14233","inReplyTo":"200807010220.44657.chriscool@tuxfamily.org","subject":"Re: [PATCH] bisect: error out when given any good rev that is not an ancestor of the bad rev","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-01T01:13:16Z","receivedAt":"2008-07-01T01:13:16Z","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> Another option is to introduce a switch to \"git bisect start\", \n> perhaps --strict, to please people who always want to use good revs that \n> are ancestor of the bad revs, so they get a nice error when this is not the \n> case.\n\nI do not see much niceness value to such an option, though.  I think such\na switch is going the opposite way from improving usability.\n\nYou cannot bisect the history with such a draconian switch when you learn\nfrom somebody that 'maint' is Ok but 'master' is broken, and you already\nknow it is a regression somewhere introduced in 'master', because you know\nyou did _not_ fix it (or at least you do not remember fixing it) only for\n'maint'.\n"}]}