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

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

[Jeff Moyer]

Hi,

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?

Thanks,
Jeff

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

[Junio C Hamano]

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.

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

[Josef Bacik]

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

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

[Jeff Moyer]

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

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

[Junio C Hamano]

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.

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

[Jeff Moyer]

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

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

[Nicolas Pitre]

On Tue, 21 Jul 2009, Junio C Hamano wrote:

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

It is short which is good.

Why not simply automatically inverting the meaning of good and
bad based on which commit is the ancestor of the other initially?


Nicolas

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

[Junio C Hamano]

Nicolas Pitre <nico@cam.org> writes:

> Why not simply automatically inverting the meaning of good and
> bad based on which commit is the ancestor of the other initially?

Because neither may be an ancestor of the other?

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

[Nicolas Pitre]

On Tue, 21 Jul 2009, Junio C Hamano wrote:

> Nicolas Pitre <nico@cam.org> writes:
> 
> > Why not simply automatically inverting the meaning of good and
> > bad based on which commit is the ancestor of the other initially?
> 
> Because neither may be an ancestor of the other?

In most cases it has to be, no?


Nicolas

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

[Junio C Hamano]

Nicolas Pitre <nico@cam.org> writes:

> On Tue, 21 Jul 2009, Junio C Hamano wrote:
>
>> Nicolas Pitre <nico@cam.org> writes:
>> 
>> > Why not simply automatically inverting the meaning of good and
>> > bad based on which commit is the ancestor of the other initially?
>> 
>> Because neither may be an ancestor of the other?
>
> In most cases it has to be, no?

Not necessarily.

I think it depends on your workflow.  When you bisect a topic branch that
forked from 'master' some time ago, it is not unreasonable to start it
with

	$ git bisect start topic master

instead of

	$ git bisect start topic $(git merge-base master topic)

Recent bisect would force you to check the merge base first as a sanity
check, but I think you already need to have determined what good and bad
means at that point if you take the route you suggested.