{"thread":{"id":"7420","subject":"[PATCH] Bisect: add checks at the beginning of \"git bisect run\".","startedAt":"2007-03-27T04:49:57Z","lastAt":"2007-04-05T08:05:18Z","messageCount":13,"participants":["Christian Couder","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"38106","messageId":"20070327064957.34dad72a.chriscool@tuxfamily.org","threadId":"7420","inReplyTo":null,"subject":"[PATCH] Bisect: add checks at the beginning of \"git bisect run\".","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2007-03-27T04:49:57Z","receivedAt":"2007-03-27T04:49:57Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"We may be able to \"run\" with only one good revision given\nand then verify that the result of the first run is bad.\nAnd perhaps also the other way around.\n\nBut for now let's check that we have at least one bad and\none good revision before we start to run.\n\nSigned-off-by: Christian Couder <chriscool@tuxfamily.org>\n---\n git-bisect.sh |    8 ++++++++\n 1 files changed, 8 insertions(+), 0 deletions(-)\n\ndiff --git a/git-bisect.sh b/git-bisect.sh\nindex fda1712..57d6754 100755\n--- a/git-bisect.sh\n+++ b/git-bisect.sh\n@@ -223,6 +223,14 @@ bisect_replay () {\n }\n \n bisect_run () {\n+    # Check that we have everything to run correctly.\n+    test -d \"$GIT_DIR/refs/bisect\" || {\n+\techo >&2 'You need to start by \"git bisect start\".'\n+\techo >&2 'And then by \"git bisect bad\" and \"git bisect good\".'\n+\texit 1\n+    }\n+    bisect_next_check fail\n+\n     while true\n     do\n       echo \"running $@\"\n-- \n1.5.1.rc2.2.gcc08\n"},{"id":"38107","messageId":"7vzm5zs1aq.fsf@assigned-by-dhcp.cox.net","threadId":"7420","inReplyTo":"20070327064957.34dad72a.chriscool@tuxfamily.org","subject":"Re: [PATCH] Bisect: add checks at the beginning of \"git bisect run\".","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-27T05:28:13Z","receivedAt":"2007-03-27T05:28:13Z","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> diff --git a/git-bisect.sh b/git-bisect.sh\n> index fda1712..57d6754 100755\n> --- a/git-bisect.sh\n> +++ b/git-bisect.sh\n> @@ -223,6 +223,14 @@ bisect_replay () {\n>  }\n>  \n>  bisect_run () {\n> +    # Check that we have everything to run correctly.\n> +    test -d \"$GIT_DIR/refs/bisect\" || {\n> +\techo >&2 'You need to start by \"git bisect start\".'\n> +\techo >&2 'And then by \"git bisect bad\" and \"git bisect good\".'\n> +\texit 1\n> +    }\n> +    bisect_next_check fail\n> +\n\nI think you shouldn't need the first \"test -d blah\"; doesn't\n\"bisect_next_check fail\" already give that message?\n\n>      while true\n>      do\n>        echo \"running $@\"\n> -- \n> 1.5.1.rc2.2.gcc08\n"},{"id":"38108","messageId":"7vmz1zs0g5.fsf@assigned-by-dhcp.cox.net","threadId":"7420","inReplyTo":"20070327064957.34dad72a.chriscool@tuxfamily.org","subject":"Re: [PATCH] Bisect: add checks at the beginning of \"git bisect run\".","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-27T05:46:34Z","receivedAt":"2007-03-27T05:46:34Z","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> We may be able to \"run\" with only one good revision given\n> and then verify that the result of the first run is bad.\n> And perhaps also the other way around.\n\nBisect fundamentally needs one bad commit (nearer to the tip,\nrelative to the good commits if you have any) to work, but there\nis no technical reason to require a good commit.\n\nIf the commit at the tip of 'master' branch is bad, it is\nentirely possible to start bisection with:\n\n\t$ git rev-list --bisect master\n\nIt will find a midpoint between the root commit and the HEAD.\n\nHowever, for a project with long history, if you immediately\nstart bisecting once you give a bad commit, it would translate\nto this rather awkward command sequence, especially when you\nalready know one good and bad commits:\n\n\t$ git bisect start\n\t$ git bisect bad master\n        ... computes the midpoint in the history, which may be\n        ... way in the past, and checkout that ancient commit\n        ... to test.  however, because you knew a much more\n        ... recent commit that is good, you do not bother to\n\t... test such an ancient one.\n\t$ git bisect good $known_good_commit\n        ... computes the midpoint between $known_good_commit and\n        ... master, and checks it out.\n\nFor a toy-sized project such as git.git itself, checking out an\nancient revision once, only to immediately check out a more\nrecent revision, is not much of an overhead, but as your project\ngrows into real size, such an unnecessary checkout would waste\ntime (because you would need to update thousands of paths, only\nto immediately discard) and buffer cache (because the more\nrecent, relevant revision would have set of paths much closer to\nwhat you originally had than the initial, wasteful checkout of\nthe ancient commit).\n\nSo our requirement to have at least one good commit is not a\nfundamental one, but only a practical one.\n\nWe could give an --immediate (or --no-good) option to 'git\nbisect bad' to start bisecting as soon as you give a single bad\ncommit.  It might turn out that the commits you test are bad all\nthe way down to the root commit, though ;-).\n"},{"id":"38117","messageId":"200703270915.12408.chriscool@tuxfamily.org","threadId":"7420","inReplyTo":"7vzm5zs1aq.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Bisect: add checks at the beginning of \"git bisect run\".","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2007-03-27T07:15:12Z","receivedAt":"2007-03-27T07:15:12Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Le mardi 27 mars 2007 07:28, Junio C Hamano a écrit :\n> Christian Couder <chriscool@tuxfamily.org> writes:\n> >\n> >  bisect_run () {\n> > +    # Check that we have everything to run correctly.\n> > +    test -d \"$GIT_DIR/refs/bisect\" || {\n> > +\techo >&2 'You need to start by \"git bisect start\".'\n> > +\techo >&2 'And then by \"git bisect bad\" and \"git bisect good\".'\n> > +\texit 1\n> > +    }\n> > +    bisect_next_check fail\n> > +\n>\n> I think you shouldn't need the first \"test -d blah\"; doesn't\n> \"bisect_next_check fail\" already give that message?\n\nWithout the first \"test -d blah\", if \"bisect start\" was not already used, \nthen the user will only see :\n\n'You need to give me at least one good and one bad revisions.'\n\nAnd then when using \"git bisect good\" or \"git bisect bad\" to give good or \nbad revision:\n\n'You need to start by \"git bisect start\"\nDo you want me to do it for you [Y/n]?'\n\nSo I thought that it would be better to tell the user upfront everything \nthat should be done.\n\nBut it's up to you.\n\nThanks,\nChristian.\n"},{"id":"38118","messageId":"7vps6vqhf3.fsf@assigned-by-dhcp.cox.net","threadId":"7420","inReplyTo":"200703270915.12408.chriscool@tuxfamily.org","subject":"Re: [PATCH] Bisect: add checks at the beginning of \"git bisect run\".","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-27T07:22:56Z","receivedAt":"2007-03-27T07:22:56Z","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> Without the first \"test -d blah\", if \"bisect start\" was not already used, \n> then the user will only see :\n>\n> 'You need to give me at least one good and one bad revisions.'\n>\n> And then when using \"git bisect good\" or \"git bisect bad\" to give good or \n> bad revision:\n>\n> 'You need to start by \"git bisect start\"\n> Do you want me to do it for you [Y/n]?'\n\nDoesn't that suggest the existing messages from \"git bisect good/bad\"\ncan use the same improvement you added only to \"bisect run\"?\n"},{"id":"38227","messageId":"200703280544.47569.chriscool@tuxfamily.org","threadId":"7420","inReplyTo":"7vmz1zs0g5.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Bisect: add checks at the beginning of \"git bisect run\".","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2007-03-28T03:44:47Z","receivedAt":"2007-03-28T03:44:47Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Le mardi 27 mars 2007 07:46, Junio C Hamano a écrit :\n\n[...]\n\n> So our requirement to have at least one good commit is not a\n> fundamental one, but only a practical one.\n>\n> We could give an --immediate (or --no-good) option to 'git\n> bisect bad' to start bisecting as soon as you give a single bad\n> commit.  It might turn out that the commits you test are bad all\n> the way down to the root commit, though ;-).\n\nYes, I plan to add some options to git bisect subcommands.\n\nFor example \"git bisect run\" could accept the following options:\n\n--not\nmark current revision as bad instead of good and as good instead of bad\n\n--strict\nall exit code except 0 and 1 abort the bisect run process\n\n--good <rev1>\n--bad <rev2>\nuse rev1 as good and rev2 as bad\n\n--check or --test\nrun the script once and then do nothing if the result is good\n\nAre there other options that people want ?\n\nThanks,\nChristian.\n"},{"id":"38233","messageId":"7vk5x1ly2g.fsf@assigned-by-dhcp.cox.net","threadId":"7420","inReplyTo":"200703280544.47569.chriscool@tuxfamily.org","subject":"Re: [PATCH] Bisect: add checks at the beginning of \"git bisect run\".","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-28T05:46:47Z","receivedAt":"2007-03-28T05:46:47Z","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> For example \"git bisect run\" could accept the following options:\n>\n> --not\n> mark current revision as bad instead of good and as good instead of bad\n\nDo you mean this is a useful option when the \"run-script\"\nreports failure with 0 exit and success with non-zero exit?  In\nother words, exit code has reversed meanings from the usual?\n\n> --strict\n> all exit code except 0 and 1 abort the bisect run process\n\nThis I can understand...\n\n> --good <rev1>\n> --bad <rev2>\n> use rev1 as good and rev2 as bad\n\nI am not sure what you mean by these two.\n\n> --check or --test\n> run the script once and then do nothing if the result is good\n\nHow would you use this?  Presumably this makes the command keep\nrunning while the commit is bad, until you hit a good commit and\nthen stop.\n\nI wonder why this is useful.\n\nStopping at a commit that happens to be good, without narrowing\nthe range all the way down is sometimes useful, as you can\nusually guess which one of the remaining commits are likely to\nbe involved with the problem you are seeing, when the remaining\nset is sufficiently narrow.  But how narrow the remaining set is\ndoes not have much to do with your finding a good commit for the\nfirst time.  If you start from a single bad commit at the tip of\n10-year old project, you would probably try 5-year old commit,\nwhich may well be good (or maybe it is too old to be relevant)\nand then this option would make the cycle stop, and you have\n5-year worth of history still left to be bisected.  I am not\nsure what the assumed workflow would be after that point.\n"},{"id":"38235","messageId":"200703280952.57058.chriscool@tuxfamily.org","threadId":"7420","inReplyTo":"7vk5x1ly2g.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Bisect: add checks at the beginning of \"git bisect run\".","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2007-03-28T07:52:56Z","receivedAt":"2007-03-28T07:52:56Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Le mercredi 28 mars 2007 07:46, Junio C Hamano a écrit :\n> >\n> > --not\n> > mark current revision as bad instead of good and as good instead of bad\n>\n> Do you mean this is a useful option when the \"run-script\"\n> reports failure with 0 exit and success with non-zero exit?  In\n> other words, exit code has reversed meanings from the usual?\n\nYes, for example to find when a string first appeared in a file one could \nuse:\n\ngit bisect run --not grep string my_file\n\ninstead of something like\n\ngit bisect run ! grep string my_file\n\nor\n\ngit bisect run 'grep string my_file ; test $? -ne 0'\n\n> > --good <rev1>\n> > --bad <rev2>\n> > use rev1 as good and rev2 as bad\n>\n> I am not sure what you mean by these two.\n\nFor example one could write:\n\ngit bisect run --good rev1 --bad rev2 my_script\n\ninstead of\n\ngit bisect start\ngit bisect good rev1\ngit bisect bad rev2\ngit bisect run my_script\n\n> > --check or --test\n> > run the script once and then do nothing if the result is good\n>\n> How would you use this? \n\nFor example if you know that the last nightly build \ntagged \"nightly_2007_03_27\" was ok, you could use:\n\ngit bisect start\ngit bisect good nightly_2007_03_27\ngit bisect run --check make > /dev/null || {\n\t# extract commit and author email address from \"$GIT_DIR/BISECT_RUN\"\n\t# and send flame to author who broke the build with the commit\n}\n\nto automatically check that current source code builds ok.\n\nOr you could use it in some test suites to automatically find the first bad \ncommit (and be able to flame the author :-) in case one test fails.\n\nChristian.\n"},{"id":"38236","messageId":"7vbqidls13.fsf@assigned-by-dhcp.cox.net","threadId":"7420","inReplyTo":"200703280952.57058.chriscool@tuxfamily.org","subject":"Re: [PATCH] Bisect: add checks at the beginning of \"git bisect run\".","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-28T07:57:12Z","receivedAt":"2007-03-28T07:57:12Z","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> git bisect run --not grep string my_file\n>\n> instead of something like\n>\n> git bisect run ! grep string my_file\n\nHow's the former more useful than the latter was what I was\nwondering but I do not care too deeply.\n\n> For example one could write:\n>\n> git bisect run --good rev1 --bad rev2 my_script\n>\n> instead of\n>\n> git bisect start\n> git bisect good rev1\n> git bisect bad rev2\n> git bisect run my_script\n\nLikewise.\n\n>> > --check or --test\n>> > run the script once and then do nothing if the result is good\n>>\n>> How would you use this? \n>\n> For example if you know that the last nightly build \n> tagged \"nightly_2007_03_27\" was ok, you could use:\n>\n> git bisect start\n> git bisect good nightly_2007_03_27\n> git bisect run --check make > /dev/null || {\n> \t# extract commit and author email address from \"$GIT_DIR/BISECT_RUN\"\n> \t# and send flame to author who broke the build with the commit\n> }\n>\n> to automatically check that current source code builds ok.\n\nAs I said, bisect fundamentally needs one bad commit to start\nbisecting, so after you give only one good commit, it would not\nmove to bisect branch nor suggest which commit to test.  I\nassume you intend to run the test on the tip of the current\nbranch here, but then your \"git bisect run --check ./run-script\"\nis equivalent to running ./run-script and checking the exit\nvalue.\n\nIn other words, the above would be equilvalent to\n\n  git bisect start\n  git bisect good nightly_2007_03_27\n  make >/dev/null || {\n\t  git bisect bad\n          git bisect run make >/dev/null\n          # extract commit and author email address from \"$GIT_DIR/BISECT_RUN\"\n          # and send flame to author who broke the build with the commit\n  }\n\nI happen to find the latter easier to read as a shell script.\n"},{"id":"38281","messageId":"200703290702.47972.chriscool@tuxfamily.org","threadId":"7420","inReplyTo":"7vbqidls13.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Bisect: add checks at the beginning of \"git bisect run\".","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2007-03-29T05:02:47Z","receivedAt":"2007-03-29T05:02:47Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Le mercredi 28 mars 2007 09:57, Junio C Hamano a écrit :\n>\n> In other words, the above would be equilvalent to\n>\n>   git bisect start\n>   git bisect good nightly_2007_03_27\n>   make >/dev/null || {\n> \t  git bisect bad\n>           git bisect run make >/dev/null\n>           # extract commit and author email address from\n> \"$GIT_DIR/BISECT_RUN\" # and send flame to author who broke the build with\n> the commit }\n\nYes, it would be equivalent but a little shorter.\n\nSo while we are at it, what about a new subcommand \"git bisect test\" that \ncould be used like this:\n\ngit bisect test good_rev my_script\n\nequivalent to the following :\n\nmy_script || {\n\tgit bisect start &&\n\tgit bisect bad &&\n\tgit bisect good good_rev &&\n\tgit bisect run my_script\n}\n\nthat could be used like this:\n\ngit bisect test good_rev my_script || {\n\techo >&2 \"my_script failed but 'git bisect test' failed too\"\n\texit 1\n}\ntest -f \"$GIT_DIR/BISECT_RUN\" && {\n\t# extract commit and author email address from\n\t# \"$GIT_DIR/BISECT_RUN\" and send flames\n\tgit bisect reset\n}\n\nThanks,\nChristian.\n"},{"id":"38282","messageId":"7virck8txp.fsf@assigned-by-dhcp.cox.net","threadId":"7420","inReplyTo":"200703290702.47972.chriscool@tuxfamily.org","subject":"Re: [PATCH] Bisect: add checks at the beginning of \"git bisect run\".","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-29T06:06:42Z","receivedAt":"2007-03-29T06:06:42Z","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 while we are at it, what about a new subcommand \"git bisect test\" that \n> could be used like this:\n\nYou are using it as a building block for nightly script, so\nthere are already certain logic around the call to \"git bisect\"\nin your script.  I do not think we would necessarily want more\nsubcommands to \"git bisect\", unless the new subcommands truly is\ngenerally applicable.\n\nUnlike \"run\", \"test\" expects a workflow where there always is\none recent good_rev and there might be at most one single\nbreakage introduced since the last nightly build.  For that\nparticular use case, it might be handier to be able to write a\nsingle line:\n\n> git bisect test good_rev my_script\n\ncompared to:\n\n> my_script || {\n> \tgit bisect start &&\n> \tgit bisect bad &&\n> \tgit bisect good good_rev &&\n> \tgit bisect run my_script\n> }\n\nbut it is not useful for use case other than that.  Maybe we\nalready know more than one good commits that are on the side\nbranch to limit the bisect space in project specific way.\n\nThe thing is, the more you add policy to a building block, the\nless generally useful the building block becomes.  The reason I\ntook \"git bisect run\" is because for the simplest use case, it\ncan be used without writing a specialized \"run script\" (you can\ngive \"make test\" to it, for example).  And more importantly, in\nthe case of \"run\", there is not much policy involved.  It is a\ngood command to have in a building block because what it does is\npurely to automate what the user would perform mechanically by\nhand anyway.  One thing I would want is to keep the bisect\nsubcommands to the minimum, so that people can easily use it as\na building block in their automation, without having to hunt\nthrough many workflow-specific subcommands that do not suit\ntheir particular needs.  Catering to their particular needs are\nbetter handled in their scripts, including your \"I have one\nknown good commit, I do not know if the tip is good, and I want\nto dig down from the tip only when the tip is bad\" case.\n\nIf you want to add value to bisect, here are two I can think of,\none almost trivial, and the other a bit harder.\n\n(1) One bad commit is fundamentally needed for bisect to run,\n    and if we beforehand know more good commits, we can narrow\n    the bisect space down without doing the whole tree checkout\n    every time we give good commits.  I think it may be a good\n    idea to have:\n\n\tgit bisect start [$bad [$good1 $good2...]] [-- <paths>...]\n\n    as a short-hand for this command sequence:\n\n\tgit bisect start\n        git bisect bad $bad\n        git bisect good $good1 $good2...\n\n    That would be a good script-shorterner, without limiting it to\n    any specific use scenario.\n\n(2) There is no technical reason to have a good commit for\n    bisect to run, other than you _often_ do not want the first\n    mid-point checkout before you give good ones to it.  But\n    sometimes, you may not know even if something _ever_ worked,\n    IOW, even the root commit might not be good.  In such a\n    case, being able to bisect having only one bad commit and no\n    good commit would be handy.  For this, bisect_next_check\n    needs to be tweaked.  Probably a transcript for such a\n    feature would go like this:\n\n\t$ git bisect start\n        $ git bisect bad HEAD\n        $ git bisect next ; echo $?\n        You need to give me at least one good and one bad revisions,\n\twith \"git bisect good\" and \"git bisect bad\".\n\t1\n\t$ git bisect next --without-good\n\tBisecting: 4321 revisions left to test after this\n\t[deadcafedeadcafedeadcafedeadcafedeadcafe] an ancient commit\n\t$ git bisect bad\n\tBisecting: 2152 revisions left to test after this\n\t[edeadcafedeadcafedeadcafedeadcafedeadcaf] a more ancient commit\n"},{"id":"38683","messageId":"200704051001.52592.chriscool@tuxfamily.org","threadId":"7420","inReplyTo":"7virck8txp.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Bisect: add checks at the beginning of \"git bisect run\".","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2007-04-05T08:01:52Z","receivedAt":"2007-04-05T08:01:52Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Le jeudi 29 mars 2007 08:06, Junio C Hamano a écrit :\n\n[...]\n\n> The thing is, the more you add policy to a building block, the\n> less generally useful the building block becomes.  The reason I\n> took \"git bisect run\" is because for the simplest use case, it\n> can be used without writing a specialized \"run script\" (you can\n> give \"make test\" to it, for example).  And more importantly, in\n> the case of \"run\", there is not much policy involved.  It is a\n> good command to have in a building block because what it does is\n> purely to automate what the user would perform mechanically by\n> hand anyway.  One thing I would want is to keep the bisect\n> subcommands to the minimum, so that people can easily use it as\n> a building block in their automation, without having to hunt\n> through many workflow-specific subcommands that do not suit\n> their particular needs. \n\nI understand this.\n\n> Catering to their particular needs are \n> better handled in their scripts, including your \"I have one\n> known good commit, I do not know if the tip is good, and I want\n> to dig down from the tip only when the tip is bad\" case.\n\nBut I think this is not a specific need. Many people are doing nightly \nbuilds and it's a good practice, so we should encourage them by making it \nas easy as possible.\n\nPerhaps a new git subcommand instead of a git bisect subcommand.\n\nFor a nightly build you want to do something like:\n\nmy_build_script || {\n\tgit bisect start &&\n\tgit bisect bad &&\n\tgit bisect good good_rev &&\n\tgit bisect run my_script\n}\n\n> If you want to add value to bisect, here are two I can think of,\n> one almost trivial, and the other a bit harder.\n>\n> (1) One bad commit is fundamentally needed for bisect to run,\n>     and if we beforehand know more good commits, we can narrow\n>     the bisect space down without doing the whole tree checkout\n>     every time we give good commits.  I think it may be a good\n>     idea to have:\n>\n> \tgit bisect start [$bad [$good1 $good2...]] [-- <paths>...]\n>\n>     as a short-hand for this command sequence:\n>\n> \tgit bisect start\n>         git bisect bad $bad\n>         git bisect good $good1 $good2...\n>\n>     That would be a good script-shorterner, without limiting it to\n>     any specific use scenario.\n>\n> (2) There is no technical reason to have a good commit for\n>     bisect to run, other than you _often_ do not want the first\n>     mid-point checkout before you give good ones to it.  But\n>     sometimes, you may not know even if something _ever_ worked,\n>     IOW, even the root commit might not be good.  In such a\n>     case, being able to bisect having only one bad commit and no\n>     good commit would be handy.  For this, bisect_next_check\n>     needs to be tweaked.  Probably a transcript for such a\n>     feature would go like this:\n>\n> \t$ git bisect start\n>         $ git bisect bad HEAD\n>         $ git bisect next ; echo $?\n>         You need to give me at least one good and one bad revisions,\n> \twith \"git bisect good\" and \"git bisect bad\".\n> \t1\n> \t$ git bisect next --without-good\n> \tBisecting: 4321 revisions left to test after this\n> \t[deadcafedeadcafedeadcafedeadcafedeadcafe] an ancient commit\n> \t$ git bisect bad\n> \tBisecting: 2152 revisions left to test after this\n> \t[edeadcafedeadcafedeadcafedeadcafedeadcaf] a more ancient commit\n"},{"id":"38684","messageId":"200704051005.19076.chriscool@tuxfamily.org","threadId":"7420","inReplyTo":"200704051001.52592.chriscool@tuxfamily.org","subject":"Re: [PATCH] Bisect: add checks at the beginning of \"git bisect run\".","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2007-04-05T08:05:18Z","receivedAt":"2007-04-05T08:05:18Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Ooops again! Sorry, this message was sent before it was finished.\nPlease ignore it. I will resend a good one latter.\n\nThanks,\nChristian.\n\n\nLe jeudi 5 avril 2007 10:01, Christian Couder a écrit :\n> Le jeudi 29 mars 2007 08:06, Junio C Hamano a écrit :\n>\n> [...]\n>\n> > The thing is, the more you add policy to a building block, the\n> > less generally useful the building block becomes.  The reason I\n> > took \"git bisect run\" is because for the simplest use case, it\n> > can be used without writing a specialized \"run script\" (you can\n> > give \"make test\" to it, for example).  And more importantly, in\n> > the case of \"run\", there is not much policy involved.  It is a\n> > good command to have in a building block because what it does is\n> > purely to automate what the user would perform mechanically by\n> > hand anyway.  One thing I would want is to keep the bisect\n> > subcommands to the minimum, so that people can easily use it as\n> > a building block in their automation, without having to hunt\n> > through many workflow-specific subcommands that do not suit\n> > their particular needs.\n>\n> I understand this.\n>\n> > Catering to their particular needs are\n> > better handled in their scripts, including your \"I have one\n> > known good commit, I do not know if the tip is good, and I want\n> > to dig down from the tip only when the tip is bad\" case.\n>\n> But I think this is not a specific need. Many people are doing nightly\n> builds and it's a good practice, so we should encourage them by making it\n> as easy as possible.\n>\n> Perhaps a new git subcommand instead of a git bisect subcommand.\n>\n> For a nightly build you want to do something like:\n>\n> my_build_script || {\n> \tgit bisect start &&\n> \tgit bisect bad &&\n> \tgit bisect good good_rev &&\n> \tgit bisect run my_script\n> }\n\n[...]\n"}]}