Anders Kaseorg <andersk@xxxxxxx> writes:
> ‘git bisect reset’ could already checkout an arbitrary commit if you
> were on a detached HEAD before starting the bisection. This lets you
> specify an arbitrary commit to ‘git bisect reset <commit>’.
>
> This also provides a way to clean the bisection state without moving
> HEAD: ‘git bisect reset HEAD’.
>
> Signed-off-by: Anders Kaseorg <andersk@xxxxxxx>
> ---
> git-bisect.sh | 3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/git-bisect.sh b/git-bisect.sh
> index 6f6f039..d319b9f 100755
> --- a/git-bisect.sh
> +++ b/git-bisect.sh
> @@ -311,8 +311,7 @@ bisect_reset() {
> }
> case "$#" in
> 0) branch=$(cat "$GIT_DIR/BISECT_START") ;;
> - 1) git show-ref --verify --quiet -- "refs/heads/$1" ||
> - die "$1 does not seem to be a valid branch"
> + 1) git rev-parse --verify "$1^{commit}" || exit
> branch="$1" ;;
> *)
> usage ;;
Thanks.
The "one parameter" case dates back to the original bisect implementation
in commit 8cc6a08 (Making it easier to find which change introduced a bug,
2005-07-30), and the only reason of existence for that case was that the
code looked like this back then:
bisect_reset() {
case "$#" in
0) branch=master ;;
1) test -f "$GIT_DIR/refs/heads/$1" || {
echo >&2 "$1 does not seem to be a valid branch"
exit 1
}
branch="$1" ;;
*)
usage ;;
esac
...
An important difference to notice, compared to a more recent version, is
that we did not remember (nor use) the original branch, and without an
argument we always switched to 'master'. Back then, the user who started
bisecting a side branch needed to remember the name of the branch before
starting the bisection, and needed to give that to the reset subcommand.
Because we remember where we came from these days, I do not think it makes
much sense to even keep this "one parameter" case, let alone extending
this interface to allow switching to an arbitrary commit.
I even think that the support for an explicit branch name in the reset
subcommand should eventually be deprecated, perhaps unless it matches what
is stored in BISECT_START.
The documentation, does not even talk about what the optional <branch>
argument is good for, even though it lists the optional <branch> in the
synopsis section.
Having said all that, four years and two months are looooooong time in git
timescale, and I am discounting, without any evidence to judge either way,
the possibility that people may have learned during that time to (ab)use
this as a (very useful?) shortcut to finish the current bisection and
switch to some entirely different branch.
I offhand do not see a good rationale for such a shortcut to finish bisect
and switch to another branch (IOW, I understand "it is shorter to type",
but I do not see "it is often done and very useful"), but I am open to be
enlightened by a workflow where such a shortcut is useful.
--
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