git bisect problems/ideas

> 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.

> 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.

> Christian Couder wrote:
> 
> > 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.
> 
> Any pointers to such a discussion or patch?  Maybe whatever small
> detail caused it to be forgotten could be fixed...

>>> 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.
>>
>> Any pointers to such a discussion or patch?  Maybe whatever small
>> detail caused it to be forgotten could be fixed...
>
> http://thread.gmane.org/gmane.comp.version-control.git/86063

> SZEDER Gábor wrote:
>> On Mon, Jan 17, 2011 at 05:51:33AM -0600, Jonathan Nieder wrote:
>>> Christian Couder wrote:
>
>>>> 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.
>>>
>>> Any pointers to such a discussion or patch?  Maybe whatever small
>>> detail caused it to be forgotten could be fixed...
>>
>> http://thread.gmane.org/gmane.comp.version-control.git/86063

> A better link for those who are thinking of picking up the topic might
> be [1].
>
> The problems were:
>
>  - error messages refer to "good" and "bad" with the original,
>   unreversed meaning, which could be confusing (but see later in the
>   thread!).
>  - "git bisect visualize" doesn't get the memo about the new worldview.
>  - it seems that some people lost interest after a while.
>
> None of these seems totally fatal --- as a new feature, it would not
> be breaking anyone's workflow, especially if the potentially confusing
> bits are clearly documented.

> Hi,
>
>> Aaron S. Meurer wrote:
>
>>> 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 does "git bisect reset HEAD"]
>
> FWIW I like the idea.  I end up using "git bisect reset" by accident
> from time to time and it is almost never what I want, especially
> after working on something else for a few days[1].
>

> My only worry is that it could be confusing --- what if a person,
> intending to run "git bisect reset", runs "git bisect stop" instead?
> To mitigate that, the stop subcommand could print the name of the
> start commit so such a user knows what to check out to get back to
> a familiar state.
>
> Christian Couder wrote:
>
>> 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.
>
> Any pointers to such a discussion or patch?  Maybe whatever small
> detail caused it to be forgotten could be fixed...
>
> Ciao,
> Jonathan
>
> [1] compare am --abort:
> http://thread.gmane.org/gmane.comp.version-control.git/164002

> 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.

> On Jan 17, 2011, at 2:38 AM, Christian Couder <christian.couder@gmail.com>
> wrote:
>
>> 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.
>>
>
> Well that's amazing to me. How on Earth fo you manage stuff?

>> If more people want it, yeah, we can create such a shortcut. But you
>> can also use a git alias for that.
>>
>
> Can you alias "git bisect stop", or would you have to alias "git
> bisect-stop"?

>> 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
>>
>
> I don't understand how this can only be one way?  Isn't this symmetric?  In
> other words, how is it different from
>
> A-B-C-D-E <-- dev
>    \F-G <-- master
>
> as far as bisect is concerned? Or maybe I am not entirely clear on what you
> are saying.

> Well, bugs are usually fixed within days after they have been
> reported. Otherwise they are usually documented in the code or in the
> documentation or in the test suite (with test_expect_failure).
>
> For the rest we rely on people remembering what happened and on
> people's mailing list searching skills ;-)

> Christian Couder <christian.couder@gmail.com> writes:
>
>> Well, bugs are usually fixed within days after they have been
>> reported. Otherwise they are usually documented in the code or in the
>> documentation or in the test suite (with test_expect_failure).
>>
>> For the rest we rely on people remembering what happened and on
>> people's mailing list searching skills ;-)
>
> Not really.
>
> What we do is to take advantage of the fact that issues people do care
> about are important ones, and others that nobody cares about are not worth
> pursuing.
>
> In a sense, "people forgetting" is a lot more important than "people
> remembering" to filter unimportant issues (issues that are so unimportant
> that even the original complainer does not bother to come back and
> re-raise it).

> Christian Couder <christian.couder@gmail.com> writes:
> 
>> Well, bugs are usually fixed within days after they have been
>> reported. Otherwise they are usually documented in the code or in the
>> documentation or in the test suite (with test_expect_failure).
>> 
>> For the rest we rely on people remembering what happened and on
>> people's mailing list searching skills ;-)
> 
> Not really.
> 
> What we do is to take advantage of the fact that issues people do care
> about are important ones, and others that nobody cares about are not worth
> pursuing.
> 
> In a sense, "people forgetting" is a lot more important than "people
> remembering" to filter unimportant issues (issues that are so unimportant
> that even the original complainer does not bother to come back and
> re-raise it).

>>> 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
>>> 
>> 
>> I don't understand how this can only be one way?  Isn't this symmetric?  In
>> other words, how is it different from
>> 
>> A-B-C-D-E <-- dev
>>    \F-G <-- master
>> 
>> as far as bisect is concerned? Or maybe I am not entirely clear on what you
>> are saying.
> 
> Yes, it is symmetric, so we cannot just automatically reverse the
> meanning because there is no "after" or "before" relationship between
> "dev" and "master".
> 
> Best regards,
> Christian.

>>>
>>> I don't understand how this can only be one way?  Isn't this symmetric?  In
>>> other words, how is it different from
>>>
>>> A-B-C-D-E <-- dev
>>>    \F-G <-- master
>>>
>>> as far as bisect is concerned? Or maybe I am not entirely clear on what you
>>> are saying.
>>
>> Yes, it is symmetric, so we cannot just automatically reverse the
>> meanning because there is no "after" or "before" relationship between
>> "dev" and "master".
>
> I think I understand.  What if something works in A, gets broken in C, stays broken in E, but gets fixed in G?  Should it maybe be implied by whichever one is marked as good first, A or G, if you trying to find the fix or the break?

> On Wed, Jan 19, 2011 at 8:44 PM, Aaron S. Meurer <asmeurer@gmail.com> wrote:
> > If no, I think --reverse is actually a suitable fix.
>
> Yeah, but I think that what Dscho started was probably better. The
> problem is just that it is not so simple to implement and no one yet
> has been interested enough or took enough time to finish it.

> > > If no, I think --reverse is actually a suitable fix.
> >
> > Yeah, but I think that what Dscho started was probably better. The
> > problem is just that it is not so simple to implement and no one yet
> > has been interested enough or took enough time to finish it.
> 
> Let me throw in an idea:
> 
> Add two new sub-commands:
> 
> * 'git bisect regression': this is a synonym for 'git bisect start'.
> 
> * 'git bisect improvement': this also starts a bisection, but subsequently the 
>    operation of 'git bisect good' and 'git bisect bad' is reversed.