git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Andreas Ericsson <ae@op5.se>
Date
Nov 20, 2008, 08:44 UTC
Message-ID
<4925236B.3020404@op5.se>
In-Reply-To
<7vljvfswek.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
Show 52 quoted lines
> "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
Previous: Junio C Hamano
Message 2 of 2 in “Re: git bisect do not work when good reversion is newer than bad reversion”
  1. Junio C HamanoNov 19, 2008
  2. Andreas EricssonNov 20, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.