git bisect problems/ideas

git bisect problems/ideas

[Aaron S. Meurer]

First off, do you guys have an issue tracker?  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.  

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.

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)?

Aaron Meurer

Re: git bisect problems/ideas

[Christian Couder]

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.

Re: git bisect problems/ideas

[Jonathan Nieder]

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

Re: git bisect problems/ideas

[SZEDER Gábor]

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


Best,
Gábor

Re: git bisect problems/ideas

[Jonathan Nieder]

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.

Thanks.

[1] http://thread.gmane.org/gmane.comp.version-control.git/86089/focus=86161

Re: git bisect problems/ideas

[Christian Couder]

2011/1/17 Jonathan Nieder <jrnieder@gmail.com>:
> 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

Thanks for the link.

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

Yeah, some things have changed since that time, so it may be more
involved now, but otherwise I think it would be good to have.

Thanks,
Christian.

Re: git bisect problems/ideas

[Aaron S. Meurer]

On Jan 17, 2011, at 4:51 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:

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

Things never get quite that bad for me brcause I gave the git_ps1 in  
my $PS1, so it tells me when I am bisecting and so I never forget to  
reset soon after I am done.  Ditto for am.

Aaron Meurer

> 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

Re: git bisect problems/ideas

[Aaron S. Meurer]

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?

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

Yes, of course. :)


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

Can you alias "git bisect stop", or would you have to alias "git  
bisect-stop"?

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

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.

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

This would be an acceptable solution to me (--reverse with asking).

Aaron Meurer

Re: git bisect problems/ideas

[Christian Couder]

On Mon, Jan 17, 2011 at 7:23 PM, Aaron S. Meurer <asmeurer@gmail.com> wrote:
> 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?

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 ;-)

>> 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"?

I think you have to alias "git bisect-stop".

I am not sure because when I use aliases I prefer to use shell aliases like:

alias gst='git status'

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

Re: git bisect problems/ideas

[Junio C Hamano]

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

Re: git bisect problems/ideas

[Christian Couder]

On Tue, Jan 18, 2011 at 7:34 PM, Junio C Hamano <gitster@pobox.com> wrote:
> 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).

Thanks for the clarification, now I feel much better about how well I
am doing regarding the mailing list :-)
Christian.

Re: git bisect problems/ideas

[Aaron S. Meurer]

So if I care about this issue I should keep bumping it until it gets fixed?

Aaron Meurer

On Jan 18, 2011, at 11:34 AM, Junio C Hamano wrote:

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

Re: git bisect problems/ideas

[Junio C Hamano]

"Aaron S. Meurer" <asmeurer@gmail.com> writes:

> So if I care about this issue I should keep bumping it until it gets fixed?

Depends on your definition of "bumping".  If it means "whining repeatedly
without adding anything to help resolving the issue", then no.

I thought the previous discussion was stuck after a small step by Dscho in
the right direction because nobody followed through?

Re: git bisect problems/ideas

[Aaron S. Meurer]

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

If no, I think --reverse is actually a suitable fix.

Aaron Meurer

Re: git bisect problems/ideas

[Christian Couder]

On Wed, Jan 19, 2011 at 8:44 PM, Aaron S. Meurer <asmeurer@gmail.com> wrote:
>>>
>>> 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?

In this case, if we are given "git bisect bad E" and "git bisect good
A", yes, as A is before E, we must suppose that we are looking for the
break.

But if we are given "git bisect bad E" and "git bisect good G", we
have to suppose that we are looking for the break too. There are many
good reasons for that:

- it's the logical default for bisect,
- if what is wanted is the fix, there has been for a long time the
possibility to just switch "bad" and "good",
- the user might not even realize that E and G have no "after" or
"before" relationship.

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

Best regards,
Christian.

Re: git bisect problems/ideas

[Johannes Sixt]

On Freitag, 21. Januar 2011, Christian Couder wrote:
> 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.

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.

-- Hannes

Re: git bisect problems/ideas

[Jakub Narebski]

Johannes Sixt <j6t@kdbg.org> writes:

> On Freitag, 21. Januar 2011, Christian Couder wrote:
> > 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.
> 
> 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.

I like this!

-- 
Jakub Narebski
Poland
ShadeHawk on #git