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

From: Josef Bacik <josef@redhat.com>
Date: Jul 21, 2009, 20:28 UTC
Message-ID: <20090721202848.GA3453@localhost.localdomain>
In-Reply-To: <7vfxcpdbsh.fsf@alter.siamese.dyndns.org>

On Tue, Jul 21, 2009 at 01:24:46PM -0700, Junio C Hamano wrote:

Show 21 quoted lines

> 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