Junio C Hamano <gitster@xxxxxxxxx> writes: > 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. 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 -- 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