"Ramkumar Ramachandra" <r@xxxxxxxxxxxx> 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.
