Josef Bacik <josef@xxxxxxxxxx> writes: > On Tue, Jul 21, 2009 at 01:24:46PM -0700, Junio C Hamano wrote: >> Jeff Moyer <jmoyer@xxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html