Re: git bisect bad @

[Junio C Hamano <gitster@pobox.com>]

"Ramkumar Ramachandra" <r@artagnon.com> writes:

> I bumped my head thrice (yes, thrice!) by using `git bisect bad
> @`. The error displayed to me at the end of one run was the
> following:
>
>   Cela signifie que le bogue été corrigé entre ea3595845f5013359b2ba4402f948e454350a74c et 
>   [2e100906d5d0c276335665ffefedb906d21165ca ea3595845f5013359b2ba4402f948e454350a74c].
>   error: la bissection a échoué : 'git bisect--helper --bisect-state (null)' a retourné le code erreur -3
>
> After the third attempt, I realized: ah yes, computers aren't magic; git-bisect.sh is basically a stupid shell script (no offense!).
>
> Perhaps git-bisect.sh can ref-parse the arguments before starting its work? Agreed, none of the refs are expected to change during its operation, with the exception of the sneaky `@`.

As far as I know, the first thing it does to the command line is to
turn them into concrete object names.  I do not doubt that you had
some problem, and I do not doubt that it was with "git bisect bad"
with arguments, but I somehow doubt your diagnosis is correct.

In git-bisect.sh, we see:

        case "$#" in
        0)
                usage ;;
        *)
                cmd="$1"
                get_terms
                shift
                case "$cmd" in
                help)
                        git bisect -h ;;
                start)
                        git bisect--helper --bisect-start "$@" ;;
                bad|good|new|old|"$TERM_BAD"|"$TERM_GOOD")
                        git bisect--helper --bisect-state "$cmd" "$@" ;;

So "git bisect--helper --bisect-state bad HEAD" is run in your case.
Now in builtin/bisect--helper.c::bisect_state(), here is what
happpens:

 * argc is checked to make sure at least one arg is there to give
   the 'state' (i.e. good or bad)

 * if there is no arg, the revision that is marked as the given
   'state' defaults to "HEAD"

 * each remaining arg is first passed to get_oid(), turned into a
   commit object.

All of the above should happen way before bisect_next_all() calls
check_good_are_ancestors_of_bad(), that eventually calls
handle_bad_merge_base() where your "The merge base X is bad" error
message comes from.

So, perhaps there is something you are not quite telling us,
e.g. your problem happens during a replay an old bisect session
after HEAD has moved---if we had a bug that records symbolic object
names in the replay log, it may produce a nonsense result in such a
case (but I doubt that is the case---I am reasonably sure that the
log also records concrete object names)?

Perhaps you can try again with a better minimum reproducible
example?

Thanks.