ubuntu-bugcontrol team mailing list archive

[Seth Forshee <seth.forshee@xxxxxxxxxxxxx>]

On Mon, Jan 21, 2013 at 05:38:18PM -0600, Christopher M. Penalver wrote:
> Seth:
> 
> Thank you for the suggestion. However, I tested reverse mainline
> kernel commit bisecting and got the following:
> cd ~/Desktop && git clone
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> linux-stable && cd linux-stable && git bisect start && git bisect good
> 8b827c60a1d984ef8c3ed175c99a33dd451348ff && git bisect bad
> 74ddcdb868a84f4a9f65e33c1ca0d24e1134e53a
> 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?

Let me check my assumption first. By "reverse bisect" I assume you mean
bisecting to find the commit which fixes a bug rather than the commit
which introduces it. Is this correct?

Under that assumption, in your example 8b827c would not have the bug
(i.e. it's the "good" commit, so you should mark it bad) and 74ddcd
would have the bug (i.e. it's the "bad" commit, so you should mark it
good). So your invocation ought to be:

 $ git bisect 8b827c 74ddcd

(alternate version of what you did, git bisect start <bad> [<good>]).

Make sense?

Seth

> It seems git is not as intuitive as expected to do reverse mainline
> kernel commit bisects via switching good and bad. Worst case scenario,
> one could eye ball commits via gitk. But, it would be nice if this
> could be done via a command line procedure similar to a normal bisect.
> 
> Does an alternative command line procedure exist, or is eye balling it
> the only way to go?
> 
> -- 
> Christopher M. Penalver
> E-Mail: christopher.m.penalver@xxxxxxxxx
> 
> On Wed, Jan 2, 2013 at 10:03 AM, Seth Forshee
> <seth.forshee@xxxxxxxxxxxxx> wrote:
> > On Mon, Dec 17, 2012 at 09:13:50AM -0600, Christopher M. Penalver wrote:
> >> Dear Ubuntu Kernel Team:
> >>
> >> Hello. I am contacting you to inquire about bug
> >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1063804 . The
> >> original reporter has identified a fix for the issue in the mainline
> >> kernel, going from version v3.7-rc3 to v3.7-rc4.
> >>
> >> As no procedure currently exists for those not familiar with reverse
> >> mainline kernel commit bisecting at
> >> https://wiki.ubuntu.com/Kernel/KernelBisection , and the bug is Status
> >> Confirmed, would you like to see the Status changed to Triaged?
> >>
> >> This report is not the only one where the next step would be a reverse
> >> mainline kernel commit bisect (ex.
> >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1074349 ).
> >> However, due to the above, and because I am not familiar with how to
> >> do this myself, I am unable to advise others in this.
> >
> > To do a reverse bisect the only thing you need to do differently is
> > switch the definitions of "good" and "bad". So if a commit exhibits the
> > problematic behavior you mark it as good, if not then you mark it as
> > bad.
> >
> > Seth