Le vendredi 11 juillet 2008, Johannes Schindelin a écrit : > Hi, > > On Fri, 11 Jul 2008, Christian Couder wrote: > > Le jeudi 10 juillet 2008, Junio C Hamano a écrit : > > > - "Test this merge-base before going forward, please" will add > > > typically only one round of check (if you have more merge bases > > > between good and bad, you need to test all of them are good to be > > > sure), so it is not "slower nor more complex". > > > > By "slower" I meant that it would need more rounds of check on average. > > By "more complex" I meant that more code is needed. > > > > And I think you are right, all the merge bases need to be tested so I > > will send a patch on top of the patch discussed here. > > Good luck. This will open the scenario where people use a proper > ancestor as "good" revision. In this case, you test that. If a proper ancestor is used as good rev, then the merge base between this good rev and the bad rev is this good rev, and as it is known to be good it doesn't need to be tested by the user. I think my patch handles this well. > If it is > "bad" you report that it is the _first_ one. > > 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). I think that users don't and can't always know what they are doing. If there is a revert in a branch for example, how can they know all the bugs that it fixes? > Trying to be too clever here might just make the whole tool rather > useless. I don't think so. I think that if user can trust "git bisect" more, they will use it more, and in more automated ways and everyone will win in the end. 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
