Re: [RFE] allow git bisect to figure out in which revision a bug was fixed

[Josef Bacik <josef@redhat.com>]

On Tue, Jul 21, 2009 at 01:24:46PM -0700, Junio C Hamano wrote:
> Jeff Moyer <jmoyer@redhat.com> writes:
> 
> > As a distro kernel grunt, I sometimes find myself in the situation of
> > having to track down the commit that fixed a given problem so that I can
> > backport it to an older kernel.  Sometimes I'm smart enough to figure it
> > out myself, other times I'm not.  ;-)  It would be helpful if git bisect
> > could help figure out in what commit a bug was fixed as opposed to
> > introduced.  Is there any interest in implementing such a feature?
> 
> Doesn't that already exist?
> 
> You are hunting for an existence of the bug, so any commit that is buggy
> (with respect to the bug you are interested in) is *GOOD*.  The tip of the
> upstream is *BAD* in that it does not have your favourite bug anymore.
> 
> You bisect that history down, and will find the first *BAD* commit.
> 
> Now, why is that commit the procedure finds is *BAD*, again?  Yup, because
> it does not have your favourite bug anymore.  And why is that so?
> 
> Because the commit fixed that bug.

Sure, but as one who has used this procedure several times before, it is very
error prone, on my side because I'm a big goober.  I have a tendancy to get my
wires crossed and get dumped out at a commit that doesnt make sense (my latest
attempt put me out at a merge commit).  Sure its my fault for not being able to
keep it straight, theres no arguing that, it still would be nice for there to be
a way to remove as much human error from the process as possible.  Thanks,

Josef