Stephan Beyer <s-be...@gmx.net> writes:
> +Bisect next
> +~~~~~~~~~~~
> +
> +Sometimes it can be necessary to check out other branches during a bisect
> +session. If you want to check out the next commit of the bisection again,
> +simply issue the command:
> +
> +------------
> +$ git bisect next
> +------------
Hmph, I am not quite sure what you mean by checking out other
branches during a bisect session.
During bisection, you are on a detached HEAD with refs/bisect/*
holding the current state, and "next" indeed is a way to recompute
the commit to be tested based on that state.
But I wonder if it is safe and sane to encourage "checking out other
branches during a bisect session." as you cannot tell what other
crazy things they will do while on "other branches". I do not think
we even try to (and I do not think we should) handle a case where
the user tries to merge another branch, sees conflicts and says
"bisect next" without cleaning up, for example.
> +Another typical use case of this command is when you have marked a commit
> +as bad but you do not know a good commit. Instead of crawling through the
> +history yourself, let this command check out a commit for you.
I would say this is the only sensible use of "next", but as you
cannot see ;-) in the comment from the pre-context of the patch
below, "have bad but not good. we could bisect althoguh this is less
optimum.", I am not sure if it is a good idea to say "is also helpful"
as if we are encouraging such a usage.
> OPTIONS
> -------
> --no-checkout::
> diff --git a/git-bisect.sh b/git-bisect.sh
> index 5d1cb00..5c93a27 100755
> --- a/git-bisect.sh
> +++ b/git-bisect.sh
> @@ -334,16 +334,10 @@ bisect_next_check() {
> *)
> bad_syn=$(bisect_voc bad)
> good_syn=$(bisect_voc good)
> - if test -s "$GIT_DIR/BISECT_START"
> - then
> -
> - eval_gettextln "You need to give me at least one
> \$bad_syn and one \$good_syn revision.
> -(You can use \"git bisect \$bad_syn\" and \"git bisect \$good_syn\" for
> that.)" >&2
> - else
> - eval_gettextln "You need to start by \"git bisect
> start\".
> -You then need to give me at least one \$good_syn and one \$bad_syn revision.
> -(You can use \"git bisect \$bad_syn\" and \"git bisect \$good_syn\" for
> that.)" >&2
> - fi
> + eval_gettextln "You need to give me at least one \$bad_syn
> revision.
> +Use \"git bisect \$bad_syn\" for that. One \$good_syn revision is also
> helpful
> +for bisecting (use \"git bisect \$good_syn\"). If you do not know one
> \$good_syn
> +revision, you can use \"git bisect next\" to find one." >&2
> exit 1 ;;
> esac
> }
> @@ -677,7 +671,6 @@ case "$#" in
> skip)
> bisect_skip "$@" ;;
> next)
> - # Not sure we want "next" at the UI level anymore.
> bisect_next "$@" ;;
> visualize|view)
> bisect_visualize "$@" ;;
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
