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

[Jeff Moyer <jmoyer@redhat.com>]

Junio C Hamano <gitster@pobox.com> writes:

> 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,
>
> There indeed was discussions along the line of adding "fixed" and "broken"
> as synonyms to "bad" and "good".
>
> I mildly suspect that it is a matter of opinion if such an addition would
> make things better or more confusing, because the word "broken" feels more
> strongly associated with "bad" than "good".
>
> Perhaps "wanted" and "unwanted" makes a better pair of more neutral words?
> In bisect, we do not want to judge commits' in absolute goodness scale.
> It is all relative to what _you_ as the person who runs bisect want, and
> in that sense the original terminology "good/bad" was suboptimal.

I think good and bad are fine.  I like HPA's idea of just making a git
bisect reverse.
  http://thread.gmane.org/gmane.comp.version-control.git/120013/focus=120107

Cheers,
Jeff