Hi Ralf, Maybe you should have made it more obvious that this patch is a RFC for a proposed feature (say, in subject line). >'git bisect fix' teaches bisect about when some known bug was >introduced and when it was fixed, so that bisect can merge in >the fix when needed into new test candidates. This sounds like a great idea. I do have myself to do conditional cherry-picks from bisect scripts, to deal with this problem. >If some bug was fixed by a merge only, the more general notation >"f_1 ^b_1 ^b_1' ..." could apply. Some more precise example may make this case more clear. +Fixing up known bugs +~~~~~~~~~~~~~~~~~~~~ + +If many revisions are broken due to some unrelated but known issue that +is easily fixed, you might want to prefer fixing it up temporarily. It seems natural for "bisect run" to use this mechanism. What about the non-automated process ? We may want to get the fixes applied, or to only list available fixes to the user so he can "git merge" them manually, or maybe an interactive selection mode ? Probably something to be chosen via some config variable and flags, in a separate patch of the would-be series. But what happens initially will be a good thing to document. +If `<commit1>` introduces a bug fixed by `<commit2>`, instruct bisect +to merge the latter before testing a commit that contains the former: + +------------ +$ git bisect fix <commit1>..<commit2> +------------ Usually, a bug also gets fixed by an official commit which does not fulfill the constraint of being branched at the faulty one. In this case you don't want to merge the fix if such a fix is already included, and thus you will need a way to specify "alternate fixes" to control this. +A single `<commit>` acts as if `<commit>^..<commit>` was specified. +Fix statements can be repeated for every known bug, and are valid until +the bisection state is cleaned up with reset. That is on the safe side, but we may at some point want some sort of "repository of fixes", where this info gets stored for easy reuse on subsequent bisections. +Any bisect action that causes a new commit to be chosen will try to merge +the needed fixes and fail if they do not merge cleanly. maybe "... similar to what happens when a bisect-run script terminates with exit code greated than 127." ? -- Yann Dirson - Bertin Technologies -- 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