Give an example on how to bisect when older revisions need a hot-fix to build, run or test. Triggered by the binutils/kernel issue at http://thread.gmane.org/gmane.comp.gnu.binutils/52601/focus=1112779 Signed-off-by: Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> --- The example script is basically Junio's, with merge rather than cherry-pick. Documentation/git-bisect.txt | 33 +++++++++++++++++++++++++++++++++ 1 files changed, 33 insertions(+), 0 deletions(-) diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt index 47e8b1e..989e223 100644 --- a/Documentation/git-bisect.txt +++ b/Documentation/git-bisect.txt @@ -294,6 +294,39 @@ It is safer if both "test.sh" and "check_test_case.sh" are outside the repository to prevent interactions between the bisect, make and test processes and the scripts. +* Automatically bisect with temporary modifications (hot-fix): ++ +------------ +$ cat ~/test.sh +#!/bin/sh + +# tweak the working tree by merging the hot-fix branch +# and then attempt a build +if git merge --no-commit hot-fix && + make +then + # run project specific test and report its status + ~/check_test_case.sh + status=$? +else + # tell the caller this is untestable + status=125 +fi + +# undo the tweak to allow clean flipping to the next commit +git reset --hard + +# return control +exit $status +------------ ++ +This applies modifications from a hot-fix branch before each test run, +e.g. in case your build or test environment changed so that older +revisions may need a fix which newer ones have already. (Make sure the +hot-fix branch is based off a commit which is contained in all revisions +which you are bisecting, so that the merge does not pull in too much, or +use `git cherry-pick` instead of `git merge`.) + * Automatically bisect a broken test case: + ------------ -- 1.7.4.1.404.g62d316 -- 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