Olliver Schinagl <oliver@xxxxxxxxxxx> writes:
> While completly orthonogal, I agree; it would be nice to have and
> 'abuse' for the bisect-skip usecase. So if we ignore the fact that it
> can be abused for this (which I don't think is a bad thing, it just
> risks the recursive issue Phillip mentioned.
I do not see the "recursive" issue here, though. If we had such a
mechansim, those whose test cannot be driven by "bisect run" can
still use the "--post-checkout" and "--pre-resume" options, where
the post-checkout option names a file that has:
#!/bin/sh
if git merge-base --is-ancestor $the_other_bug HEAD
then
# we need the fix
git cherry-pick --no-commit $fix_for_the_other_bug ||
exit 125
fi
in it. There is no "recursive"-ness here. And then after manually
testing the checked out stuff (with tweak, thanks to the post-checkout
script), they can now say "git bisect good/bad/skip" and that is
when their --pre-resume script kicks in, which may do
#!/bin/sh
git reset --hard ;# undo the damage done by post-checkout
before the bisect machinery goes and picks the next commit to test.
Notice that I still kept the "exit 125" in the above post-checkout
example? That is where the "bisect next" that picked the commit to
test, checked out that commit and updated the working tree, and run
your post-checkout script, can be told that the version checked out
is untestable and to be skipped. So such a post-checkout script can
be treated as a strict superset of --skip-when script we have been
discussing.
Needless to say, if we were to do this, we probably should let
"bisect run" also pay attention to these two scripts. They are most
likely to become new parameters specified when "bisect start" is run
to be recorded as one of the many states "git bisect" creates.
