Re: git bisect do not work when good reversion is newer than bad reversion

Re: git bisect do not work when good reversion is newer than bad reversion

[Junio C Hamano]

"Cai, Crane" <Crane.Cai@amd.com> writes:

> Hi Junio,
>
> Sorry to disturb you. Here the requirement I met can not find answer
> from website. That's why I directly ask you.
>
> I need to use "git bisect" to find what patch can fix a problem.
> I found v2.6.25 has this problem.
> And v2.6.26 does NOT has this problem.
>
> Then I use bisect as this:
>
> #git bisect start
> #git bisect good v2.6.26
> #git bisect bad v2.6.25
>
> No reversion cut via these steps. Do you know whether git command can
> achieve this requirement or not?

You can use "git bisect" to find a single change that fixed the issue
(_provided if_ such a single change exists).  There is a small mental
trick you need to exercise.

First, realize that bisect is about "it used to be like this, but later it
turned into that.  Where did that single transition from this to that
happened"?  Usually, "this" is "had this particular bug and was broken"
and "that" is "that bug was fixed and things work smoothly".  In your
case, however, "this" is "broken" and "that" is "fixed".  IOW, the
question you ask "bisect" is "it used to be broken but later it was fixed;
where did that exactly happen?".

The mental trick is to swap "good" and "bad" in order to adjust to your
use, because you are using bisect in a reverse way from the usual.  Usual
case uses "good" mark "this" while "bad" is used to mark "that" in the
sentence "it used to be like this, but later it turned into that".

So what you would do is...

	(1) First of all, write on a piece of paper:

	    good - the version _STILL_ has the bug.
            bad  - the version does not have the bug _ANYMORE_

	(2) Start with "git bisect v2.6.25 v2.6.26";

        (3) As you test each revision, look at the memo you made.  Say
            "good" if it still has the bug you are interested in; say
            "bad" if it does not have the bug anymore..

    cf. http://thread.gmane.org/gmane.comp.version-control.git/86063

By the way, I usually drop requests-for-help on the floor unless it is
CC'ed to the mailing list, because my time spent on writing the response
like this message will be wasted and wouldn't help the git community at
all.  I simply do not have enough time to give unpaid support for
individuals.  I am making exception this time only because I am waiting
for something and I happen to have nothing else to do while doing so.

Please send this kind of request-for-help to <git@vger.kernel.org>, the
main mailing list, to which anybody can send messages without subscribing.

Re: git bisect do not work when good reversion is newer than bad reversion

[Andreas Ericsson]

Junio C Hamano wrote:
> "Cai, Crane" <Crane.Cai@amd.com> writes:
> 
>> Hi Junio,
>>
>> Sorry to disturb you. Here the requirement I met can not find answer
>> from website. That's why I directly ask you.
>>
>> I need to use "git bisect" to find what patch can fix a problem.
>> I found v2.6.25 has this problem.
>> And v2.6.26 does NOT has this problem.
>>
>> Then I use bisect as this:
>>
>> #git bisect start
>> #git bisect good v2.6.26
>> #git bisect bad v2.6.25
>>
>> No reversion cut via these steps. Do you know whether git command can
>> achieve this requirement or not?
> 
> You can use "git bisect" to find a single change that fixed the issue
> (_provided if_ such a single change exists).  There is a small mental
> trick you need to exercise.
> 
> First, realize that bisect is about "it used to be like this, but later it
> turned into that.  Where did that single transition from this to that
> happened"?  Usually, "this" is "had this particular bug and was broken"
> and "that" is "that bug was fixed and things work smoothly".  In your
> case, however, "this" is "broken" and "that" is "fixed".  IOW, the
> question you ask "bisect" is "it used to be broken but later it was fixed;
> where did that exactly happen?".
> 
> The mental trick is to swap "good" and "bad" in order to adjust to your
> use, because you are using bisect in a reverse way from the usual.  Usual
> case uses "good" mark "this" while "bad" is used to mark "that" in the
> sentence "it used to be like this, but later it turned into that".
> 
> So what you would do is...
> 
> 	(1) First of all, write on a piece of paper:
> 
> 	    good - the version _STILL_ has the bug.
>             bad  - the version does not have the bug _ANYMORE_
> 
> 	(2) Start with "git bisect v2.6.25 v2.6.26";
> 
>         (3) As you test each revision, look at the memo you made.  Say
>             "good" if it still has the bug you are interested in; say
>             "bad" if it does not have the bug anymore..
> 
>     cf. http://thread.gmane.org/gmane.comp.version-control.git/86063
> 

Or start your bisect run with this:
git config alias.fixed "!git bisect bad"
git config alias.buggy "!git bisect good"

Then you can run "git fixed" if the bug is fixed, and "git buggy" if the
bug is present.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231