Michael J Gruber [off-list ref] writes:
+* Bisect with compatibility hotfix:
++
+------------
+$ git bisect start HEAD HEAD~10 -- # culprit is among the last 10
+$ git bisect run sh -c "git cherry-pick -n hotfix || exit 125; make || exit 125; ~/check_test_case.sh"
+------------
++
+Does the same as the previous example, but applies an additional patch
+before building. This is useful when your build or test environment changed so
+that older revisions may need a fix which newer ones have already.
+
It is a good idea to add an example that shows it is perfectly Ok to muck
with the working tree before testing, but I don't see this patch as such.
First of all, doesn't bisect_checkout does its job with "checkout -q"
without "-f"? How would that interact with running cherry-pick _every
time_ you check commit to be tested out? In some situations it may work
OK by accident, but as an example that is likely to be cut&pasted I think
we should show a reasonably safer way than this.
There likely are more than one hot-fixes; it would make more sense to
illustrate merging a hot-fixes branch using "git merge --no-commit" than
using cherry-pick.
But the above are minor; the biggest issue I have with this patch is that
it breaks the train of thought for people who are reading from top to
bottom.
Look at what is there currently. It starts simple (single command run via
"run" interface), and demonstrates that anything complex can be easily
managed with a fully-spelled-out "one test wrapper that builds and then
runs test" example, to show the most generic way you can use. It then
introduces special exit codes in the script, as that form is easier to
read than a single command line.
It then shows, as a final aside, that it isn't strictly required to use a
wrapper script and you could use "sh -c" to wrap that in the command line,
which may be easier to use when (and only when IMO---if you will have
anything that needs debugging then you are better off with the first
approach) the command line you use for testing is trivial.
I think a new example you are adding would fit much better in the flow if
you replaced the example it refers to as "the previous example". There
are that "previous example" that uses the "check_test_case.sh", and the
one before that one that uses "make test"; they are duplicates that do not
add much value and we would add value by dropping one of them. It
probably is better to remove the "make test" one and keep the
"check_test_case.sh" one, as long as you explain "check_test_case.sh"
sufficiently well, because the latter is more generally applicable.
The new example would fit well as an illustration of what you _could_ have
in test.sh script when you need to do more elaborate set-up before testing
each revision, e.g., you tweak the working tree with hotfix before running
"make || exit 125", and clean that up after you tested. The core of the
new section would look like this:
$ cat test.sh
#!/bin/sh
# tweak the working tree by merging the hot-fix branch
# and then attempt a build
if git cherry-pick --no-commit hot-fix &&
make
then
# run project specific test and report its status
./test.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
Streamline the presentation of "bisect run" by removing one example
which does not introduce new concepts.
Signed-off-by: Michael J Gruber <redacted>
---
Documentation/git-bisect.txt | 34 ++++++++--------------------------
1 files changed, 8 insertions(+), 26 deletions(-)
diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
index c39d957..47e8b1e 100644
--- a/Documentation/git-bisect.txt
+++ b/Documentation/git-bisect.txt
@@ -274,53 +274,35 @@ $ git bisect start HEAD origin -- # HEAD is bad, origin is good
$ git bisect run make test # "make test" builds and tests
------------
-* Automatically bisect a broken test suite:
-+
-------------
-$ cat ~/test.sh
-#!/bin/sh
-make || exit 125 # this skips broken builds
-make test # "make test" runs the test suite
-$ git bisect start v1.3 v1.1 -- # v1.3 is bad, v1.1 is good
-$ git bisect run ~/test.sh
-------------
-+
-Here we use a "test.sh" custom script. In this script, if "make"
-fails, we skip the current commit.
-+
-It is safer to use a custom script outside the repository to prevent
-interactions between the bisect, make and test processes and the
-script.
-+
-"make test" should "exit 0", if the test suite passes, and
-"exit 1" otherwise.
-
* Automatically bisect a broken test case:
+
------------
$ cat ~/test.sh
#!/bin/sh
make || exit 125 # this skips broken builds
-~/check_test_case.sh # does the test case passes ?
+~/check_test_case.sh # does the test case pass?
$ git bisect start HEAD HEAD~10 -- # culprit is among the last 10
$ git bisect run ~/test.sh
------------
+
-Here "check_test_case.sh" should "exit 0" if the test case passes,
+Here we use a "test.sh" custom script. In this script, if "make"
+fails, we skip the current commit.
+"check_test_case.sh" should "exit 0" if the test case passes,
and "exit 1" otherwise.
+
-It is safer if both "test.sh" and "check_test_case.sh" scripts are
+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 a broken test suite:
+* Automatically bisect a broken test case:
+
------------
$ git bisect start HEAD HEAD~10 -- # culprit is among the last 10
$ git bisect run sh -c "make || exit 125; ~/check_test_case.sh"
------------
+
-Does the same as the previous example, but on a single line.
+This shows that you can do without a run script if you write the test
+on a single line.
Author
------
--
1.7.4.1.404.g62d316
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 <redacted>
---
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