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, Josef -- 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