Messages in this thread | | | Date | Tue, 05 Jun 2012 10:56:54 -0600 | From | David Ahern <> | Subject | Re: git bisect and perf |
| |
On 6/5/12 9:51 AM, Roland Dreier wrote: > On Tue, Jun 5, 2012 at 8:29 AM, David Ahern<dsahern@gmail.com> wrote: >> # git bisect good v2.6.38 >> Some good revs are not ancestor of the bad rev. >> git bisect cannot work properly in this case. >> Maybe you mistake good and bad revs? > > git bisect is telling you what is wrong -- as the man page says: > > This command uses git rev-list --bisect to help drive the binary > search process to find which change introduced a bug, given an old > "good" commit object name and a later "bad" commit object name. > > so it assumes the good commit is older than the bad commit. > > You can actually use git bisect in your case, although it gets very confusing > unless you write yourself a little wrapper alias: just swap the meaning of > good and bad, ie do > > # git bisect start arch/x86/kernel/cpu/perf_event* > # git bisect good v2.6.35 > # git bisect bad v2.6.38 > > and try somehow to remember that when you do a test, "bad" means > PEBS works and "good" means PEBS doesn't work. > > - R.
Thanks, Roland. I'll reverse the logic.
David
| |