# Re: git bisect do not work when good reversion is newer than bad reversion 2 messages from 2008-11-19 to 2008-11-20. Participants: Junio C Hamano, Andreas Ericsson. Thread: https://gitlist.dev/t/16393 ## Junio C Hamano, 2008-11-19 13:00 Subject: Re: git bisect do not work when good reversion is newer than bad reversion Message-ID: <7vljvfswek.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vljvfswek.fsf%40gitster.siamese.dyndns.org In-Reply-To: <6077B97E85E7374DAE87B42B5AA997970D0B12@sshaexmb1.amd.com> ``` "Cai, Crane" 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 , the main mailing list, to which anybody can send messages without subscribing. ``` ## Andreas Ericsson, 2008-11-20 08:44 Subject: Re: git bisect do not work when good reversion is newer than bad reversion Message-ID: <4925236B.3020404@op5.se> URL: https://gitlist.dev/e/4925236B.3020404%40op5.se In-Reply-To: <7vljvfswek.fsf@gitster.siamese.dyndns.org> ``` Junio C Hamano wrote: > "Cai, Crane" 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 ```