On Thursday 02 July 2009, Robert Stonehouse wrote: > > In my toy example it is easy to identify featureB branch as being > independent and marking it as good - but in a real repository it would > be much harder as they might be many more merges. As Jakub said, when the current commit is untestable, "git bisect skip" is the most logical command to use. Now if you have more information than just "the current commit is untestable", for example if you know that the current commit is on a side branch that has work unrelated to the breakage you are looking for, and if you know that the branch started from a "good" commit, then you can use "git bisect good" instead, because you know the commit is good even if you have not tested it. > I think if I changed my usage of git bisect good and bad to: > good => build completes > OR a revision that does not have the new build target > bad => new build target fails > then I think it will converge to the problem commit. So perhaps this was > just an issue of semantics I'd say that it's an issue of information. If you already have the information that some commits are good before testing them, then you should use "git bisect good" even if you can't test them. Best regards, Christian. -- 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