Hi, On Thu, 10 Jul 2008, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > You are opening a can of worms here, and I doubt that this is a good idea. > > > > git-bisect as-is has very precise, and _simple_ semantics, and users > > should really know what they are doing (i.e. not marking something as > > "good" which is on a branch containing a fix). > > > > Trying to be too clever here might just make the whole tool rather > > useless. > > Have you read the original thread yet? I do not think this is trying to > be clever at all, but trying to be helpful. > > As you explained, bisection *requires* that Good is ancestor of Bad. Thanks, I got that already. Of course it can be that the user commits a pilot error and says "but that unrelated version was good", while the fork point(s) between good and bad was bad (and this might be even the intention of the user, to find _one_ commit that introduced the bug). Speaking of plural, what if some of the merge bases are good, some are bad? Without carefully thinking it through, you might even _break_ the tool. All I was proposing is keeping the current semantics, keeping the mechanism simple, and therefore reliable. Ciao, Dscho -- 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
