Re: [PATCH 01/16] bisect: write about `bisect next` in documentation
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Feb 26, 2016, 18:47 UTC
- Message-ID
- <xmqqoab3jokp.fsf@gitster.mtv.corp.google.com>
- In-Reply-To
- <1456452282-10325-2-git-send-email-s-beyer@gmx.net>
Stephan Beyer <s-beyer@gmx.net> writes:
Show 10 quoted lines
> +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.
Show 36 quoted lines
> 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 "$@" ;;