Le vendredi 11 juillet 2008, Junio C Hamano a écrit : > > But in real life, things are more like "Today's master does not work, but > I am sure it used to work at 1.5.6.2". I happen to always merge all of > 'maint' to 'master' before pushing them out, so a good topology is > guaranteed, but not everybody does this (it takes careful planning what > to apply to 'maint' and where to fork topics from, and maintainers are > not perfect): > > Good > ?---o (maint) > / > ---?---?---?---?---x (master) > MB Bad > > People _will_ face such a topology. If the users Know Better, they will > test MB=$(merge-base master maint) first to see if it is broken, and then > the world will have two possibilities: > > (1) Good > ?---o (maint) > / > ---o---?---?---?---x (master) > Good Bad > > (2) Good > ?---o (maint) > / > ---x---?---?---?---x (master) > Bad Bad > > > If (1), you go ahead with the usual bisection. If (2), you cannot even > bisect. Instead, you flip good and bad to find the "fix" in the side > branch (the answer has to be either the tip of maint or one previous in > the picture) to forward port to, either by merging 'maint' to 'master' or > cherry-picking. > > The idea to check merge-base first is about automating this process (I > admit I still haven't looked at Christian's patch text yet). Well in case (2) my patch does: ------- cat >&2 <<EOF The merge base $_badmb is bad. This means the bug has been fixed between $_badmb and $_g. EOF exit 3 ------- but this can be improved upon in some latter patches. 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
