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

[Jeff Moyer <jmoyer@redhat.com>]

Josef Bacik <josef@redhat.com> writes:

> 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,

And now that I've done the research I should have done before posting, I
see that this feature has been requested at least 2 other times.  I can
get by the way things stand, for sure, but it sounds like there's
interest in making things a bit more user friendly.

Thanks for your time.

-Jeff