Le mardi 1 juillet 2008, Junio C Hamano a écrit : > Christian Couder <chriscool@xxxxxxxxxxxxx> writes: > > Yes, but the fact is that the user may wrongly think that F is an > > ancestor of D or he may not remember/know about the rule that saying "F > > is good" means "everything from A to F is good". That's why this patch > > adds a safety net by detecting end erroring out in this case. > > Yeah, sorry about the confusion earlier. > > But I do not think forbidding forked topology very early in bisection > process is a very good idea. The user would be at loss when told: > > echo >&2 "Maybe you mistake good and bad revs?" Yeah, perhaps we should then check that it can be a mistake by testing if bad is an ancestor of good. If bad is indeed an ancestor of good, it's probably a mistake and we may even ask if the user wants good and bad to be swaped (assuming he gave only one good rev of course). > Aside from the "test a trial merge" idea I floated in the other message, > when we detect such a fork, perhaps we can suggest testing the merge base > version (B in your picture) first? We would immediately know as the user > would say "B is bad" if the topology is problematic. Yes this can be a good idea, if the user gave only one good rev. It maybe more tricky if he gave many good revs, but in this case we may perhaps drop siblings good revs as long as one good rev is an ancestor of the bad rev. > Then, we can suggest the user that breakage at D may not be a regression > but a longstanding bug that was recently fixed somewhere between B and F. > > The user then can decide to bisect to find the fix (so that it can be > cherry picked on top of D) or merge F into D to propagate the fix forward > if it is not important to find out which exact commit fixed the issue. > > Hmm? Yeah that might be a plan. Another option is to introduce a switch to "git bisect start", perhaps --strict, to please people who always want to use good revs that are ancestor of the bad revs, so they get a nice error when this is not the case. Thanks, 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
