{"thread":{"id":"28304","subject":"[BUG] git bisect start fails when stale bisect data is left behind","startedAt":"2011-09-05T11:15:34Z","lastAt":"2011-09-07T10:51:22Z","messageCount":6,"participants":["Joel Kaasinen","Christian Couder","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"174861","messageId":"CAC6WLetwT9UvBY_=Nf38hhkyU1mhmdWHWqscf3ebba1WRGS1LQ@mail.gmail.com","threadId":"28304","inReplyTo":null,"subject":"[BUG] git bisect start fails when stale bisect data is left behind","fromName":"Joel Kaasinen","fromEmail":"joel@zenrobotics.com","sentAt":"2011-09-05T11:15:34Z","receivedAt":"2011-09-05T11:15:34Z","isPatch":false,"sender":{"key":"joel@zenrobotics.com","avatar":null},"body":"Hi,\n\nJust bumped into a weird bug: bisect refused to start. It seems some\nprevious bisect had left around state that referred to a\nnow-nonexistent branch.\n\nHow to reproduce:\n$ echo foo > .git/BISECT_START\n$ git bisect start HEAD HEAD^\n\nFails with \"fatal: invalid reference:\" on git 1.7.6.\n\n–J\n\nPS. Please CC me when answering, I'm not subscribed\n"},{"id":"174902","messageId":"CAP8UFD1h059dOyjszcP-qFauyho78c0RHBMQsGOPFgzZtp+7vg@mail.gmail.com","threadId":"28304","inReplyTo":"CAC6WLetwT9UvBY_=Nf38hhkyU1mhmdWHWqscf3ebba1WRGS1LQ@mail.gmail.com","subject":"Re: [BUG] git bisect start fails when stale bisect data is left behind","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2011-09-06T07:48:34Z","receivedAt":"2011-09-06T07:48:34Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi,\n\nOn Mon, Sep 5, 2011 at 1:15 PM, Joel Kaasinen wrote:\n> Hi,\n>\n> Just bumped into a weird bug: bisect refused to start. It seems some\n> previous bisect had left around state that referred to a\n> now-nonexistent branch.\n>\n> How to reproduce:\n> $ echo foo > .git/BISECT_START\n> $ git bisect start HEAD HEAD^\n>\n> Fails with \"fatal: invalid reference:\" on git 1.7.6.\n\nYeah, it looks like a very old behavior.\nI'd suggest a simple improvement in the error message like this:\n\ndiff --git a/git-bisect.sh b/git-bisect.sh\nindex c21e33c..bd7155b 100755\n--- a/git-bisect.sh\n+++ b/git-bisect.sh\n@@ -67,7 +67,8 @@ bisect_start() {\n then\n # Reset to the rev from where we started.\n start_head=$(cat \"$GIT_DIR/BISECT_START\")\n- git checkout \"$start_head\" -- || exit\n+ git checkout \"$start_head\" -- ||\n+ die \"Could not checkout previous start point\n'$start_head'. Try 'git bisect reset ' first.\"\n else\n # Get rev from where we start.\n case \"$head\" in\n\nIf there is no objection I will provide a proper patch.\n\nThanks,\nChristian.\n"},{"id":"174939","messageId":"7vehztaan4.fsf@alter.siamese.dyndns.org","threadId":"28304","inReplyTo":"CAP8UFD1h059dOyjszcP-qFauyho78c0RHBMQsGOPFgzZtp+7vg@mail.gmail.com","subject":"Re: [BUG] git bisect start fails when stale bisect data is left behind","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-09-06T16:38:55Z","receivedAt":"2011-09-06T16:38:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Christian Couder writes:\n\n>> How to reproduce:\n>> $ echo foo > .git/BISECT_START\n>> $ git bisect start HEAD HEAD^\n>>\n>> Fails with \"fatal: invalid reference:\" on git 1.7.6.\n>\n> Yeah, it looks like a very old behavior.\n> I'd suggest a simple improvement in the error message like this:\n>\n> diff --git a/git-bisect.sh b/git-bisect.sh\n> index c21e33c..bd7155b 100755\n> --- a/git-bisect.sh\n> +++ b/git-bisect.sh\n> @@ -67,7 +67,8 @@ bisect_start() {\n> then\n> # Reset to the rev from where we started.\n> start_head=$(cat \"$GIT_DIR/BISECT_START\")\n> - git checkout \"$start_head\" -- || exit\n> + git checkout \"$start_head\" -- ||\n> + die \"Could not checkout previous start point\n> '$start_head'. Try 'git bisect reset ' first.\"\n\nI do not necessarily think this is a bug to begin with --- the user had a\nbad state, and bisect stopped without doing further damage.\n\nThe real question is what the sensible suggestion/advice the new message\nshould give. It would have to involve bisect reset in the end to get rid\nof the stale bisect state, but wouldn't the user potentially lose some\nother state if s/he blindly followed the die message's suggestion and ran\n\"bisect reset\"?\n"},{"id":"174976","messageId":"201109070648.21211.chriscool@tuxfamily.org","threadId":"28304","inReplyTo":"7vehztaan4.fsf@alter.siamese.dyndns.org","subject":"Re: [BUG] git bisect start fails when stale bisect data is left behind","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2011-09-07T04:48:20Z","receivedAt":"2011-09-07T04:48:20Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Tuesday 06 September 2011 18:38:55 Junio C Hamano wrote:\n> Christian Couder writes:\n> >> How to reproduce:\n> >> $ echo foo > .git/BISECT_START\n> >> $ git bisect start HEAD HEAD^\n> >> \n> >> Fails with \"fatal: invalid reference:\" on git 1.7.6.\n> > \n> > Yeah, it looks like a very old behavior.\n> > I'd suggest a simple improvement in the error message like this:\n> > \n> > diff --git a/git-bisect.sh b/git-bisect.sh\n> > index c21e33c..bd7155b 100755\n> > --- a/git-bisect.sh\n> > +++ b/git-bisect.sh\n> > @@ -67,7 +67,8 @@ bisect_start() {\n> > \n> > then\n> > \n> > # Reset to the rev from where we started.\n> > start_head=$(cat \"$GIT_DIR/BISECT_START\")\n> > \n> > - git checkout \"$start_head\" -- || exit\n> > + git checkout \"$start_head\" -- ||\n> > + die \"Could not checkout previous start point\n> > '$start_head'. Try 'git bisect reset ' first.\"\n> \n> I do not necessarily think this is a bug to begin with --- the user had a\n> bad state, and bisect stopped without doing further damage.\n\nYeah, in fact commit f3a186ffade15f793ea17713a10e10ec4f26ff11 (bisect: improve \nerror message when branch checkout fails, Sat Apr 4, 2009) already improved \nthe error message, but probably didn't go far enough.\n\n> The real question is what the sensible suggestion/advice the new message\n> should give. It would have to involve bisect reset in the end to get rid\n> of the stale bisect state, but wouldn't the user potentially lose some\n> other state if s/he blindly followed the die message's suggestion and ran\n> \"bisect reset\"?\n\nWhen using \"git bisect start\" with an existing $GIT_DIR/BISECT_START file, the \nnext thing we do after checking out the previous head from the BISECT_START \nfile is a call to \"bisect_clean_state\". So all the previous bisect state is \ndiscarded except the previous head that is in $start_head.\n\nIf checking out the previous head fails, that probably means that the previous \nhead is bad because it has been deleted.\n\nIn this case running \"git bisect reset \" and then \"git bisect start \n...\" is ok because there is no valuable state lost compared to the situation \nwhere \"git bisect start ...\" succeeded in the first place.\n\nOf course if checking out the previous head failed because the \n$GIT_DIR/BISECT_START file has been corrupted, then it might be better to fix \nthe content of this file. But anyway if we are able to fix the content of the \nfile, for example by putting \"foobar\" in it instead of the truncated \"foo\" that \nmade the checkout fail, then running \"git bisect reset foobar\" and then \"git \nbisect start ...\" would probably do the trick too.\n\nIt wouldn't do the trick if the $GIT_DIR/BISECT_START file also needed a \npermission change or more free space on the disc or something like that. But \nin this case we will get an hopefully meaningful error message when running \n\"git bisect reset foobar\" or \"git bisect start ...\" and we would not lose \ninformation.\n\nThanks,\nChristian.\n"},{"id":"174980","messageId":"CAC6WLetO-KKkHmPHJ64rt6+BMbhUHUtNfxF3GK4obMUAuE9XXQ@mail.gmail.com","threadId":"28304","inReplyTo":"7vehztaan4.fsf@alter.siamese.dyndns.org","subject":"Re: [BUG] git bisect start fails when stale bisect data is left behind","fromName":"Joel Kaasinen","fromEmail":"joel@zenrobotics.com","sentAt":"2011-09-07T06:28:16Z","receivedAt":"2011-09-07T06:28:16Z","isPatch":false,"sender":{"key":"joel@zenrobotics.com","avatar":null},"body":"On Tue, Sep 6, 2011 at 19:38, Junio C Hamano wrote:\n> I do not necessarily think this is a bug to begin with --- the user had a\n> bad state, and bisect stopped without doing further damage.\n\nOh, actually my git-bisect man page says:\n\n\"\"\"\n Bisect reset\n After a bisect session, to clean up the bisection state and return to\n the original HEAD, issue the following command:\n\n $ git bisect reset\n\n By default, this will return your tree to the commit that was checked\n out before git bisect start. (A new git bisect start will also do that,\n as it cleans up the old bisection state.)\n\"\"\"\n\nThe parenthetical sentence seems to imply that a bisect start cleans\nout the old state. The problem is that the cleaning fails when the\nstate is bad. (Try e.g. \"git bisect start; git bisect start a b\" where\na and b are valid refs.)\n\nIt's pretty much the same to me how this gets resolved. I'm fine with\na more verbose error message from bisect start.\n\n–J\n"},{"id":"174981","messageId":"7vaaag62xh.fsf@alter.siamese.dyndns.org","threadId":"28304","inReplyTo":"CAC6WLetO-KKkHmPHJ64rt6+BMbhUHUtNfxF3GK4obMUAuE9XXQ@mail.gmail.com","subject":"Re: [BUG] git bisect start fails when stale bisect data is left behind","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-09-07T10:51:22Z","receivedAt":"2011-09-07T10:51:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Joel Kaasinen writes:\n\n> On Tue, Sep 6, 2011 at 19:38, Junio C Hamano wrote:\n>> I do not necessarily think this is a bug to begin with --- the user had a\n>> bad state, and bisect stopped without doing further damage.\n>\n> Oh, actually my git-bisect man page says:\n>\n> \"\"\"\n> Bisect reset\n> After a bisect session, to clean up the bisection state and return to\n> the original HEAD, issue the following command:\n>\n> $ git bisect reset\n>\n> By default, this will return your tree to the commit that was checked\n> out before git bisect start. (A new git bisect start will also do that,\n> as it cleans up the old bisection state.)\n> \"\"\"\n>\n> The parenthetical sentence seems to imply that a bisect start cleans\n> out the old state. The problem is that the cleaning fails when the\n> state is bad. (Try e.g. \"git bisect start; git bisect start a b\" where\n> a and b are valid refs.)\n>\n> It's pretty much the same to me how this gets resolved. I'm fine with\n> a more verbose error message from bisect start.\n\nI do not think anybody minds \"a more verbose\" message. I do mind if the\nsuggestion the message makes were \"wrong\". That is what I was questioning.\n"}]}