On Fri, Nov 02, 2007 at 11:03:36AM +0100, Andreas Ericsson wrote: > Steffen Prohaska wrote: >> On Nov 1, 2007, at 10:11 AM, Andreas Ericsson wrote: >>> >>> It's easier to bisect. If git bisect lands you on a merge-commit, >>> you need to start a new bisect for each of the parents included >>> in the merge. Hopefully the nature of the merge gives a clue so >>> the user can make an educated guess as to which parent introduced >>> the bogus commit, but for an "evil octopus" (unusual) or if the >>> merge had conflicts which were resolved in a buggy way (not >>> exactly uncommon), it can be quite a hassle to get things right. >>> With a mostly linear history, this problem goes away. >> This is really an interesting point. I did not start to use >> git bisect regularly. But I certainly plan to do so in the future. >> Couldn't bisect learn to better cope with non-linear history? > > Perhaps it could, but it's far from trivial. I started hacking on > a wrapper for git-bisect which would do just that, but gave up > rather quickly as the book-keeping required to remember each and > every parent-point tried just got out of hand, and it *still* > wouldn't run in full automatic. It broke down because I also > wanted merges on non-first-line parents to be delved into. If > that didn't happen, I wouldn't *know* the bisect would run fine > without me watching it, so then it was as useless as if I'd have > had to sit there the entire time anyway. I haven't had occasion to use git-bisect much, but I was under the impression that bisect could already handle merges, or any other shaped history just fine. If you test a merge and it is bad, git (eventually) picks a commit on one of the branches. If that commit is good, then the merge-base is good, so that the bug lies on some other branch. If that commit is bad, then the bug is on some ancestor of the branch. Thus, no need for special book keeping. Tom - 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
