{"thread":{"id":"33498","subject":"[PATCH] bisect: Store first bad commit as comment in log file","startedAt":"2013-04-13T15:22:57Z","lastAt":"2013-05-22T22:27:53Z","messageCount":11,"participants":["Torstein Hegge","Christian Couder","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"214138","messageId":"20130413152257.GB16040@pvv.ntnu.no","threadId":"33498","inReplyTo":null,"subject":"[PATCH] bisect: Store first bad commit as comment in log file","fromName":"Torstein Hegge","fromEmail":"hegge@resisty.net","sentAt":"2013-04-13T15:22:57Z","receivedAt":"2013-04-13T15:22:57Z","isPatch":true,"sender":{"key":"hegge@resisty.net","avatar":"https://avatars.githubusercontent.com/u/26041?v=4"},"body":"When bisect successfully finds a single revision, the first bad commit\nshould be shown to human readers of 'git bisect log'.\n\nThis resolves the apparent disconnect between the bisection result and\nthe log when a bug reporter says \"I know that the first bad commit is\n$rev, as you can see from $(git bisect log)\".\n\nSigned-off-by: Torstein Hegge <hegge@resisty.net>\n---\nI don't know how useful the added test is, I didn't find any existing\ntests that looks at the comment parts of bisect log.\n\n git-bisect.sh               |    8 +++++++-\n t/t6030-bisect-porcelain.sh |   18 ++++++++++++++++++\n 2 files changed, 25 insertions(+), 1 deletion(-)\n\ndiff --git a/git-bisect.sh b/git-bisect.sh\nindex 99efbe8..c58eea7 100755\n--- a/git-bisect.sh\n+++ b/git-bisect.sh\n@@ -311,7 +311,13 @@ bisect_next() {\n \tres=$?\n \n \t# Check if we should exit because bisection is finished\n-\ttest $res -eq 10 && exit 0\n+\tif test $res -eq 10\n+\tthen\n+\t\tbad_rev=$(git show-ref --hash --verify refs/bisect/bad)\n+\t\tbad_commit=$(git show-branch $bad_rev)\n+\t\techo \"# first bad commit: $bad_commit\" >>\"$GIT_DIR/BISECT_LOG\"\n+\t\texit 0\n+\tfi\n \n \t# Check for an error in the bisection process\n \ttest $res -ne 0 && exit $res\ndiff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh\nindex 2fce99a..6e65cdf 100755\n--- a/t/t6030-bisect-porcelain.sh\n+++ b/t/t6030-bisect-porcelain.sh\n@@ -741,4 +741,22 @@ test_expect_success 'bisect: demonstrate identification of damage boundary' \"\n \tgit bisect reset\n \"\n \n+cat > expected.bisect-log <<EOF\n+# bad: [32a594a3fdac2d57cf6d02987e30eec68511498c] Add <4: Ciao for now> into <hello>.\n+# good: [7b7f204a749c3125d5224ed61ea2ae1187ad046f] Add <2: A new day for git> into <hello>.\n+git bisect start '32a594a3fdac2d57cf6d02987e30eec68511498c' '7b7f204a749c3125d5224ed61ea2ae1187ad046f'\n+# good: [3de952f2416b6084f557ec417709eac740c6818c] Add <3: Another new day for git> into <hello>.\n+git bisect good 3de952f2416b6084f557ec417709eac740c6818c\n+# first bad commit: [32a594a3fdac2d57cf6d02987e30eec68511498c] Add <4: Ciao for now> into <hello>.\n+EOF\n+\n+test_expect_success 'bisect log: successfull result' '\n+\tgit bisect reset &&\n+\tgit bisect start $HASH4 $HASH2 &&\n+\tgit bisect good &&\n+\tgit bisect log >bisect-log.txt &&\n+\ttest_cmp expected.bisect-log bisect-log.txt &&\n+\tgit bisect reset\n+'\n+\n test_done\n-- \n1.7.10.4\n"},{"id":"214263","messageId":"20130415.063809.1055555229072260139.chriscool@tuxfamily.org","threadId":"33498","inReplyTo":"20130413152257.GB16040@pvv.ntnu.no","subject":"Re: [PATCH] bisect: Store first bad commit as comment in log file","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2013-04-15T04:38:09Z","receivedAt":"2013-04-15T04:38:09Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"From: Torstein Hegge <hegge@resisty.net>\nSubject: [PATCH] bisect: Store first bad commit as comment in log file\nDate: Sat, 13 Apr 2013 17:22:57 +0200\n\n> When bisect successfully finds a single revision, the first bad commit\n> should be shown to human readers of 'git bisect log'.\n> \n> This resolves the apparent disconnect between the bisection result and\n> the log when a bug reporter says \"I know that the first bad commit is\n> $rev, as you can see from $(git bisect log)\".\n\nI agree that it's a good idea to do that.\n\nI wonder if we should also write something into the bisect log if for\nexample the bisection stopped because there are only 'skip'ped commits\nleft to test. But maybe this could go into another patch after this\none.\n \n> Signed-off-by: Torstein Hegge <hegge@resisty.net>\n> ---\n> I don't know how useful the added test is, I didn't find any existing\n> tests that looks at the comment parts of bisect log.\n\nThanks for adding a test. It's always appreciated.\n\n>  git-bisect.sh               |    8 +++++++-\n>  t/t6030-bisect-porcelain.sh |   18 ++++++++++++++++++\n>  2 files changed, 25 insertions(+), 1 deletion(-)\n> \n> diff --git a/git-bisect.sh b/git-bisect.sh\n> index 99efbe8..c58eea7 100755\n> --- a/git-bisect.sh\n> +++ b/git-bisect.sh\n> @@ -311,7 +311,13 @@ bisect_next() {\n>  \tres=$?\n>  \n>  \t# Check if we should exit because bisection is finished\n> -\ttest $res -eq 10 && exit 0\n> +\tif test $res -eq 10\n> +\tthen\n> +\t\tbad_rev=$(git show-ref --hash --verify refs/bisect/bad)\n\nI had a look to make sure that refs/bisect/bad always refered to the\nfirst bad commit at this point, and it is true indeed.\n\nMaybe you could have used \"git rev-parse --verify\" instead of \"git\nshow-ref --hash --verify\". It looks simpler to me.\n\nAnd maybe, just in case, you could have added: || die \"$(gettext \"Bad rev: refs/bisect/bad\")\"\n\nOtherwise this patch looks good to me.\n\n> +\t\tbad_commit=$(git show-branch $bad_rev)\n> +\t\techo \"# first bad commit: $bad_commit\" >>\"$GIT_DIR/BISECT_LOG\"\n> +\t\texit 0\n> +\tfi\n\nThanks,\nChristian.\n"},{"id":"214266","messageId":"7v4nf82soy.fsf@alter.siamese.dyndns.org","threadId":"33498","inReplyTo":"20130413152257.GB16040@pvv.ntnu.no","subject":"Re: [PATCH] bisect: Store first bad commit as comment in log file","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-15T06:50:37Z","receivedAt":"2013-04-15T06:50:37Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Torstein Hegge <hegge@resisty.net> writes:\n\n> When bisect successfully finds a single revision, the first bad commit\n> should be shown to human readers of 'git bisect log'.\n>\n> This resolves the apparent disconnect between the bisection result and\n> the log when a bug reporter says \"I know that the first bad commit is\n> $rev, as you can see from $(git bisect log)\".\n>\n> Signed-off-by: Torstein Hegge <hegge@resisty.net>\n> ---\n> I don't know how useful the added test is, I didn't find any existing\n> tests that looks at the comment parts of bisect log.\n>\n>  git-bisect.sh               |    8 +++++++-\n>  t/t6030-bisect-porcelain.sh |   18 ++++++++++++++++++\n>  2 files changed, 25 insertions(+), 1 deletion(-)\n>\n> diff --git a/git-bisect.sh b/git-bisect.sh\n> index 99efbe8..c58eea7 100755\n> --- a/git-bisect.sh\n> +++ b/git-bisect.sh\n> @@ -311,7 +311,13 @@ bisect_next() {\n>  \tres=$?\n>  \n>  \t# Check if we should exit because bisection is finished\n> -\ttest $res -eq 10 && exit 0\n> +\tif test $res -eq 10\n> +\tthen\n> +\t\tbad_rev=$(git show-ref --hash --verify refs/bisect/bad)\n> +\t\tbad_commit=$(git show-branch $bad_rev)\n> +\t\techo \"# first bad commit: $bad_commit\" >>\"$GIT_DIR/BISECT_LOG\"\n\nAs this is \"# commented out\", replaying will safely ignore this new\nrecord, so this should be safe.\n"},{"id":"214289","messageId":"20130415095339.GA28480@pvv.ntnu.no","threadId":"33498","inReplyTo":"20130415.063809.1055555229072260139.chriscool@tuxfamily.org","subject":"Re: [PATCH] bisect: Store first bad commit as comment in log file","fromName":"Torstein Hegge","fromEmail":"hegge@resisty.net","sentAt":"2013-04-15T09:53:39Z","receivedAt":"2013-04-15T09:53:39Z","isPatch":true,"sender":{"key":"hegge@resisty.net","avatar":"https://avatars.githubusercontent.com/u/26041?v=4"},"body":"On Mon, Apr 15, 2013 at 06:38:09 +0200, Christian Couder wrote:\n> I wonder if we should also write something into the bisect log if for\n> example the bisection stopped because there are only 'skip'ped commits\n> left to test. But maybe this could go into another patch after this\n> one.\n\nYes, that would be useful, but I wasn't able to determine all the cases\nthat would be relevant to log. Only skipped commits left to test is one,\nbut bisect--helper also exits on various problems related to merge base\nhandling. The handling of problems related to inconsistent user input is\nprobably not relevant to log.\n\nI think the successful bisect case is most important to log and the one\nthat requires the least amount of invasive changes.\n\n> > diff --git a/git-bisect.sh b/git-bisect.sh\n> > index 99efbe8..c58eea7 100755\n> > --- a/git-bisect.sh\n> > +++ b/git-bisect.sh\n> > @@ -311,7 +311,13 @@ bisect_next() {\n> >  \tres=$?\n> >  \n> >  \t# Check if we should exit because bisection is finished\n> > -\ttest $res -eq 10 && exit 0\n> > +\tif test $res -eq 10\n> > +\tthen\n> > +\t\tbad_rev=$(git show-ref --hash --verify refs/bisect/bad)\n> \n> I had a look to make sure that refs/bisect/bad always refered to the\n> first bad commit at this point, and it is true indeed.\n\nAccording to Documentation/git-bisect.txt, refs/bisect/bad is the proper\nway to determine the first bad commit at the end of a bisection.\n\n> Maybe you could have used \"git rev-parse --verify\" instead of \"git\n> show-ref --hash --verify\". It looks simpler to me.\n\nI was wondering why \"git grep show-ref *.sh\" gave so few users. It looks\nlike rev-parse is more common.\n\n> And maybe, just in case, you could have added: || die \"$(gettext \"Bad rev: refs/bisect/bad\")\"\n\nYes, I should probably have done that.\n\n> Otherwise this patch looks good to me.\n\nThanks.\n\n\nTorstein\n"},{"id":"214307","messageId":"7vwqs3zvmu.fsf@alter.siamese.dyndns.org","threadId":"33498","inReplyTo":"20130415095339.GA28480@pvv.ntnu.no","subject":"Re: [PATCH] bisect: Store first bad commit as comment in log file","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-15T15:00:41Z","receivedAt":"2013-04-15T15:00:41Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Torstein Hegge <hegge@resisty.net> writes:\n\n> I was wondering why \"git grep show-ref *.sh\" gave so few users. It looks\n> like rev-parse is more common.\n\nIt is primarily because show-ref is slightly newer.  When you have a\nfull refname (e.g. refs/bisect/bad) and not an arbitrary object name\nthat is spelled in a random way (e.g. master~24):\n\n       show-ref --verify refs/bisect/bad\n\nis a perfectly valid way to make sure it _is_ an existing ref.\n\nCf. 358ddb62cfd0 (Add \"git show-ref\" builtin command, 2006-09-15)\n"},{"id":"215154","messageId":"20130422210229.GE5650@pvv.ntnu.no","threadId":"33498","inReplyTo":"20130415095339.GA28480@pvv.ntnu.no","subject":"Re: [PATCH] bisect: Store first bad commit as comment in log file","fromName":"Torstein Hegge","fromEmail":"hegge@resisty.net","sentAt":"2013-04-22T21:02:29Z","receivedAt":"2013-04-22T21:02:29Z","isPatch":true,"sender":{"key":"hegge@resisty.net","avatar":"https://avatars.githubusercontent.com/u/26041?v=4"},"body":"On Mon, Apr 15, 2013 at 11:53:39 +0200, Torstein Hegge wrote:\n> On Mon, Apr 15, 2013 at 06:38:09 +0200, Christian Couder wrote:\n> > I wonder if we should also write something into the bisect log if for\n> > example the bisection stopped because there are only 'skip'ped commits\n> > left to test. But maybe this could go into another patch after this\n> > one.\n> \n> Yes, that would be useful, but I wasn't able to determine all the cases\n> that would be relevant to log. Only skipped commits left to test is one,\n> but bisect--helper also exits on various problems related to merge base\n> handling. The handling of problems related to inconsistent user input is\n> probably not relevant to log.\n\nI took another look at this. I wasn't able to come up with anything\nuseful for the \"The merge base $rev is bad\" case, but for the \"only\nskipped commits left to test\" case one could do something like this.\n\nThere has to be a better way to get the range of possible first bad\ncommits, similar to the output of 'git log --bisect --format=\"%H\"'.\n\n--- >8 ---\nSubject: [PATCH] bisect: Log possibly bad, skipped commits at bisection end\n\nIf the bisection completes with only skipped commits left to as possible\nfirst bad commit, output the list of possible first bad commits to human\nreaders of the bisection log.\n\nSigned-off-by: Torstein Hegge <hegge@resisty.net>\n---\n git-bisect.sh               |   10 ++++++++++\n t/t6030-bisect-porcelain.sh |   20 ++++++++++++++++++++\n 2 files changed, 30 insertions(+)\n\ndiff --git a/git-bisect.sh b/git-bisect.sh\nindex c58eea7..d7518e9 100755\n--- a/git-bisect.sh\n+++ b/git-bisect.sh\n@@ -317,6 +317,16 @@ bisect_next() {\n \t\tbad_commit=$(git show-branch $bad_rev)\n \t\techo \"# first bad commit: $bad_commit\" >>\"$GIT_DIR/BISECT_LOG\"\n \t\texit 0\n+\telif test $res -eq 2\n+\tthen\n+\t\techo \"# only skipped commits left to test\" >>\"$GIT_DIR/BISECT_LOG\"\n+\t\tgood_revs=$(git for-each-ref --format=\"--not %(objectname)\" \"refs/bisect/good-*\")\n+\t\tfor skipped in $(git rev-list refs/bisect/bad $good_revs)\n+\t\tdo\n+\t\t\tskipped_commit=$(git show-branch $skipped)\n+\t\t\techo \"# possible first bad commit: $skipped_commit\" >>\"$GIT_DIR/BISECT_LOG\"\n+\t\tdone\n+\t\texit $res\n \tfi\n \n \t# Check for an error in the bisection process\ndiff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh\nindex 4d3074a..064f5ce 100755\n--- a/t/t6030-bisect-porcelain.sh\n+++ b/t/t6030-bisect-porcelain.sh\n@@ -759,4 +759,24 @@ test_expect_success 'bisect log: successfull result' '\n \tgit bisect reset\n '\n \n+cat > expected.bisect-skip-log <<EOF\n+# bad: [32a594a3fdac2d57cf6d02987e30eec68511498c] Add <4: Ciao for now> into <hello>.\n+# good: [7b7f204a749c3125d5224ed61ea2ae1187ad046f] Add <2: A new day for git> into <hello>.\n+git bisect start '32a594a3fdac2d57cf6d02987e30eec68511498c' '7b7f204a749c3125d5224ed61ea2ae1187ad046f'\n+# skip: [3de952f2416b6084f557ec417709eac740c6818c] Add <3: Another new day for git> into <hello>.\n+git bisect skip 3de952f2416b6084f557ec417709eac740c6818c\n+# only skipped commits left to test\n+# possible first bad commit: [32a594a3fdac2d57cf6d02987e30eec68511498c] Add <4: Ciao for now> into <hello>.\n+# possible first bad commit: [3de952f2416b6084f557ec417709eac740c6818c] Add <3: Another new day for git> into <hello>.\n+EOF\n+\n+test_expect_success 'bisect log: only skip commits left' '\n+\tgit bisect reset &&\n+\tgit bisect start $HASH4 $HASH2 &&\n+\ttest_must_fail git bisect skip &&\n+\tgit bisect log >bisect-skip-log.txt &&\n+\ttest_cmp expected.bisect-skip-log bisect-skip-log.txt &&\n+\tgit bisect reset\n+'\n+\n test_done\n-- \n1.7.10.4\n"},{"id":"215157","messageId":"7vr4i2nuar.fsf@alter.siamese.dyndns.org","threadId":"33498","inReplyTo":"20130422210229.GE5650@pvv.ntnu.no","subject":"Re: [PATCH] bisect: Store first bad commit as comment in log file","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-22T21:13:00Z","receivedAt":"2013-04-22T21:13:00Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Torstein Hegge <hegge@resisty.net> writes:\n\n> I took another look at this. I wasn't able to come up with anything\n> useful for the \"The merge base $rev is bad\" case, but for the \"only\n> skipped commits left to test\" case one could do something like this.\n\nWe skipped them because we can gain _no_ information from testing\nthese commits. They are not even \"possibly bad\", but are \"unknown\".\n\nSo it feels to me that by definition listing them would not be\nuseful. What am I missing?\n"},{"id":"215179","messageId":"20130422222058.GF5650@pvv.ntnu.no","threadId":"33498","inReplyTo":"7vr4i2nuar.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] bisect: Store first bad commit as comment in log file","fromName":"Torstein Hegge","fromEmail":"hegge@resisty.net","sentAt":"2013-04-22T22:20:58Z","receivedAt":"2013-04-22T22:20:58Z","isPatch":true,"sender":{"key":"hegge@resisty.net","avatar":"https://avatars.githubusercontent.com/u/26041?v=4"},"body":"On Mon, Apr 22, 2013 at 14:13:00 -0700, Junio C Hamano wrote:\n> Torstein Hegge <hegge@resisty.net> writes:\n> \n> > I took another look at this. I wasn't able to come up with anything\n> > useful for the \"The merge base $rev is bad\" case, but for the \"only\n> > skipped commits left to test\" case one could do something like this.\n> \n> We skipped them because we can gain _no_ information from testing\n> these commits. They are not even \"possibly bad\", but are \"unknown\".\n> \n> So it feels to me that by definition listing them would not be\n> useful. What am I missing?\n\nThe information lies in that those commits are the only commits with an\nunknown state. So if the bisecter hands off the bisect log to someone\nelse when they can't test further, the current status is recorded.\n\nI think part of the reason I started looking at this is that there are\nno good way to see what git said after the previous 'git bisect\ngood/bad' if the terminal output is lost. And lost terminal output is\nfairly likely if you are bisecting something that requires reboots for\neach test.\n\nBut I don't feel very strongly about this. It was based on Christian's\nidea, so unless he comes up with some compelling arguments I'll drop it.\n"},{"id":"215186","messageId":"7vwqrumbtg.fsf@alter.siamese.dyndns.org","threadId":"33498","inReplyTo":"20130422222058.GF5650@pvv.ntnu.no","subject":"Re: [PATCH] bisect: Store first bad commit as comment in log file","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-22T22:37:31Z","receivedAt":"2013-04-22T22:37:31Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Torstein Hegge <hegge@resisty.net> writes:\n\n> On Mon, Apr 22, 2013 at 14:13:00 -0700, Junio C Hamano wrote:\n>> Torstein Hegge <hegge@resisty.net> writes:\n>> \n>> > I took another look at this. I wasn't able to come up with anything\n>> > useful for the \"The merge base $rev is bad\" case, but for the \"only\n>> > skipped commits left to test\" case one could do something like this.\n>> \n>> We skipped them because we can gain _no_ information from testing\n>> these commits. They are not even \"possibly bad\", but are \"unknown\".\n>> \n>> So it feels to me that by definition listing them would not be\n>> useful. What am I missing?\n>\n> The information lies in that those commits are the only commits with an\n> unknown state. So if the bisecter hands off the bisect log to someone\n> else when they can't test further, the current status is recorded.\n\nThat is an interesting use case: \"I've narrowed it down somewhat,\nbut there are a few commits I do not have proper hardware for to\ntest them, could you take it over from here?\"\n"},{"id":"215401","messageId":"20130425.062632.630918480810226803.chriscool@tuxfamily.org","threadId":"33498","inReplyTo":"20130422222058.GF5650@pvv.ntnu.no","subject":"Re: [PATCH] bisect: Store first bad commit as comment in log file","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2013-04-25T04:26:32Z","receivedAt":"2013-04-25T04:26:32Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"From: Torstein Hegge <hegge@resisty.net>\nSubject: Re: [PATCH] bisect: Store first bad commit as comment in log file\nDate: Tue, 23 Apr 2013 00:20:58 +0200\n\n> On Mon, Apr 22, 2013 at 14:13:00 -0700, Junio C Hamano wrote:\n>> Torstein Hegge <hegge@resisty.net> writes:\n>> \n>> > I took another look at this. I wasn't able to come up with anything\n>> > useful for the \"The merge base $rev is bad\" case, but for the \"only\n>> > skipped commits left to test\" case one could do something like this.\n>> \n>> We skipped them because we can gain _no_ information from testing\n>> these commits. They are not even \"possibly bad\", but are \"unknown\".\n>> \n>> So it feels to me that by definition listing them would not be\n>> useful. What am I missing?\n> \n> The information lies in that those commits are the only commits with an\n> unknown state. So if the bisecter hands off the bisect log to someone\n> else when they can't test further, the current status is recorded.\n\nYeah, I think it is a good enough reason for your patch.\n \n> I think part of the reason I started looking at this is that there are\n> no good way to see what git said after the previous 'git bisect\n> good/bad' if the terminal output is lost. And lost terminal output is\n> fairly likely if you are bisecting something that requires reboots for\n> each test.\n\nYeah, I agree.\n\n> But I don't feel very strongly about this. It was based on Christian's\n> idea, so unless he comes up with some compelling arguments I'll drop it.\n\nI think your arguments are good enough.\n\nThanks,\nChristian.\n"},{"id":"218216","messageId":"20130522222753.GD5357@pvv.ntnu.no","threadId":"33498","inReplyTo":"20130422210229.GE5650@pvv.ntnu.no","subject":"[PATCH] bisect: Fix log output for multi-parent skip ranges","fromName":"Torstein Hegge","fromEmail":"hegge@resisty.net","sentAt":"2013-05-22T22:27:53Z","receivedAt":"2013-05-22T22:27:53Z","isPatch":true,"sender":{"key":"hegge@resisty.net","avatar":"https://avatars.githubusercontent.com/u/26041?v=4"},"body":"On Mon, Apr 22, 2013 at 23:02:29 +0200, Torstein Hegge wrote:\n> There has to be a better way to get the range of possible first bad\n> commits, similar to the output of 'git log --bisect --format=\"%H\"'.\n\nI just realized that this felt clunky because I didn't understand what\n'--not' does in git rev-list.\n\nIn the case where the range of skipped commits include a merge and\npoints in each parent marked good, I want\n\n    git rev-list bad --not good-1 good-2\n\nor \n\n    git rev-list bad ^good-1 ^good-2\n\nbut instead I did\n\n    git rev-list bad --not good-1 --not good-2\n\nwhich will include commits outside the range of skipped commits. Sorry\nabout that :/\n\n--- >8 ---\nSubject: [PATCH] bisect: Fix log output for multi-parent skip ranges\n\nThe bisect log output of skipped commits introduced in f989cac \"bisect:\nLog possibly bad, skipped commits at bisection end\" should obtain the range of\nskipped commits from\n\n    git rev-list bad --not good-1 good-2\n\nnot\n\n    git rev-list bad --not good-1 --not good-2\n\nwhen the skipped range contains a merge with good points in each parent.\n\nSigned-off-by: Torstein Hegge <hegge@resisty.net>\n---\n git-bisect.sh | 4 ++--\n 1 file changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/git-bisect.sh b/git-bisect.sh\nindex d7518e9..9f064b6 100755\n--- a/git-bisect.sh\n+++ b/git-bisect.sh\n@@ -320,8 +320,8 @@ bisect_next() {\n \telif test $res -eq 2\n \tthen\n \t\techo \"# only skipped commits left to test\" >>\"$GIT_DIR/BISECT_LOG\"\n-\t\tgood_revs=$(git for-each-ref --format=\"--not %(objectname)\" \"refs/bisect/good-*\")\n-\t\tfor skipped in $(git rev-list refs/bisect/bad $good_revs)\n+\t\tgood_revs=$(git for-each-ref --format=\"%(objectname)\" \"refs/bisect/good-*\")\n+\t\tfor skipped in $(git rev-list refs/bisect/bad --not $good_revs)\n \t\tdo\n \t\t\tskipped_commit=$(git show-branch $skipped)\n \t\t\techo \"# possible first bad commit: $skipped_commit\" >>\"$GIT_DIR/BISECT_LOG\"\n-- \n1.8.3.rc1.377.g7010c6b\n"}]}