Duncan posted on Wed, 08 Jun 2011 17:40:18 +0000 as excerpted: > FWIW, there has been discussion of another case where git bisect simply > couldn't cut it, recently, on the kernel list. Don't have time to find > the link now, but it was in an H-Online kernel log article from about a > week ago. The problem there was a fixed and then reintroduced issue.
OK, here's the H-online kernel log article. See the LKML discussion summary on pg2. (FWIW I found all three discussions interesting.) http://www.h-online.com/open/features/Kernel-Log-Hardware-and-3-0- difficulties-1254308.html And here's the direct-link to the git-bisect thread in question, "AAARGH bisection is hard", on gmane: http://thread.gmane.org/gmane.linux.kernel/1139191 >From the looks of things git-bisect is about to get some new options/ features, to help both in chasing down such issues, and with a much faster (fewer iterations) "just tell me which subsystem it's in" mode. What I think may ultimately happen is that there are three modes, the current one, the new subsystem one, and a third "hybrid mode" that would make a good new default, and that might take an iteration or two more, but will give give rather more feedback on where you are in the process. This hybrid mode would start with the subsystem mode, nail it down, then continue within the single subsystem. Because it would work in two stages and the split-points for the first wouldn't necessarily be the most efficient split-points to go all the way, it might take a couple more iterations. However, it would give much more feedback, and a reward and good stopping point much quicker, half-way thru or so, for those who would otherwise give up before they got done. Until it found the subsystem, it would tell how many more rounds until the subsystem was found as well as estimate the total to go as it does now, tho the total would be much less accurate at that point, since it'd be going by subsystem first. What would happen is that it would count the commits per remaining subssystem and would assume the worst-case subsystem would be chosen. As it began zeroing in on a specific subsystem, however, every time it eliminated the worst-case subsystem from the remaining candidates, the total rounds estimate would drop by more than one. This would make the progress seem faster to the user in much the same way as the "remaining time" estimate on a download will often drop quite fast (say 5 seconds go by but you find it has shaved a minute off the estimate) as the connection picks up speed. When it found the subsystem and/or merge-commit in question, it would announce the subsystem/merge-commit and its author/committer, and that information would then be included in the summary after each round, thus giving the user an early reward as the initial goal was reached. This would make the process far more interesting and rewarding especially for users that don't actually read code and that aren't closely enough involved with the project in question to otherwise find the process reasonably interesting, instead of the long dry slogging session of we have now. Additionally, bisect would work far more intuitively as it wouldn't be wandering into commits that appear to be before the last known good version (this can happen said commits were on a branch that wasn't yet merged), at least until the merge-commit is nailed, at which point it could explain why it might appear to be testing too early commits, because it had to nail down the commit within the merge that caused the problem. This would make the git-bisect far more user-friendly and thus far more likely for users to complete their bisects, as they'd be getting much more rewarding intermediate feedback along the way. Plus, just narrowing it to a specific merge commit is a huge step toward solving the problem, as at that point the subsystem maintainer that's familiar with the code and may well be able to spot the problem, can get involved. So for bisects that can't be finished for whatever reason, as was the above case, or which the user simply gives up on before they get it all the way done, the result is still useful. So I'm really looking forward to these changes. And since it's Linus suggesting them, they're extremely likely to happen, since he originally designed git and knows what he's talking about, and everyone involved knows that. It's not just some yahoo saying it should have such functionality, it's Linus. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman ___________________________________________________ This message is from the kde-linux mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde-linux. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
