Re: [PATCH 01/16] bisect: write about `bisect next` in documentation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Stephan Beyer <s-beyer@xxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]