Re: git bisect problems/ideas

> Hi,
>
> On Sat, Jan 15, 2011 at 8:33 AM, Aaron S. Meurer  
> <asmeurer@gmail.com> wrote:
>> First off, do you guys have an issue tracker?
>
> No, we don't. We use the mailing list.
>

>>  I asked on IRC, and someone told me that he didn't think you did,  
>> and to just post here.  After searching your websites, as far as I  
>> can tell he was right, though this is amazing to me that you can  
>> handle a project like this without an issue tracker.  If you guys  
>> really do, then sorry.  I would rather post this there than here  
>> (though if you really do, please make it more findable!)
>>
>> I just noticed this error/bug:
>>
>> git checkout test
>> git bisect start
>> <do some bisecting>
>> git branch -D test
>> <finish bisecting>
>> git bisect reset
>>
>> And it gives an error, because test has been deleted.  This is in  
>> 1.7.3.5.  Now, I looked through the log of the current master of  
>> git to see if anything has been done about this, and all I noticed  
>> was the commit 3bb8cf88247db5, which essentially improves the error  
>> message.
>>
>> Now, this is good, because it seemed to me above that I was stuck  
>> bisecting until I recreated the test branch.  I did not realize the  
>> git bisect <commit> syntax until later.
>
> You mean "git bisect reset <commit>".
>

>> But this has brought me to bother you guys about something that has  
>> been bugging me for a while. I hate git bisect reset.  90% of the  
>> time I do not want to go back to where I started bisecting.  I  
>> would much prefer to just have a git bisect stop command, which  
>> just stops the bisecting process, but leaves me where I am (like a  
>> shortcut to git bisect reset HEAD).  This would be much more  
>> symmetric with git bisect start.
>
> If more people want it, yeah, we can create such a shortcut. But you
> can also use a git alias for that.
>

>> While we are on the topic of bisecting, I have another issue.  Can  
>> we remove the restriction that a "bad" commit come after a "good"  
>> commit?  I'd say about 70% of the time I use bisect to find a  
>> commit that fixes a bug, not breaks it.  Whenever this happens, I  
>> have to bend my mind over backwards to remind myself that the good  
>> behavior is really "bad" and the bad behavior is really "good".  Is  
>> there a reason that git bisect can't just introspect from which  
>> comes earlier and which comes later to see which is "good" or  
>> "bad" (instead of just raising an error when they are in the  
>> "wrong" order)?
>
> Yeah, many people find it difficult to reverse the meaning of "bad"
> and "good" when looking for a fix. There were some suggestions at some
> points to do something about it. Some of the suggestions were to use
> some aliases for "good" and "bad", but there was no agreement. Other
> suggestions had a patch attached but the patch was not good enough or
> something.
>
> Anyway, the restriction is that the "bad" commit cannot be an ancestor
> of a "good" commit. But the "good" commits need not be all ancestors
> of the "bad" commit. For example if you have a "master" branch and a
> "dev" branch that was forked from the "master" branch at one point,
> like that:
>
> A-B-C-D-E <-- master
>      \F-G <-- dev
>

> you can use one of the branch as "bad" and the other one as "good".
> And that means that in this case we cannot automatically reverse the
> meaning of "good" and "bad".
>
> So if we ever implement a "--reverse" mode, I think that the best we
> could do if we detect that a "bad" commit is an ancestor of a "good"
> commit is to suggest the use of this "--reverse" mode. Or we could ask
> and use this mode if the answer is yes.
>
> Best regards,
> Christian.