From: Junio C Hamano <gitster@pobox.com>
To: "Ramkumar Ramachandra" <r@artagnon.com>
Cc: "Git List" <git@vger.kernel.org>
Subject: Re: git bisect bad @
Date: Sun, 09 Jan 2022 11:54:04 -0800 [thread overview]
Message-ID: <xmqqilus3ctf.fsf@gitster.g> (raw)
In-Reply-To: <1edfc6ff-4db8-447f-9eb7-85843258a286@www.fastmail.com> (Ramkumar Ramachandra's message of "Sun, 09 Jan 2022 20:29:39 +0100")
"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.
next prev parent reply other threads:[~2022-01-09 19:54 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-09 19:29 git bisect bad @ Ramkumar Ramachandra
2022-01-09 19:54 ` Junio C Hamano [this message]
2022-01-09 20:48 ` Ramkumar Ramachandra
2022-01-10 9:01 ` [PATCH] bisect: report actual bisect_state() argument on error René Scharfe
2022-01-10 10:04 ` Ramkumar Ramachandra
2022-01-10 17:06 ` git bisect bad @ Junio C Hamano
2022-01-10 21:04 ` Ramkumar Ramachandra
2022-01-12 9:04 ` René Scharfe
2022-01-12 17:50 ` Junio C Hamano
2022-01-12 18:34 ` René Scharfe
2022-01-13 5:10 ` René Scharfe
2022-01-13 9:32 ` Ramkumar Ramachandra
2022-01-13 12:28 ` Christian Couder
2022-01-13 13:55 ` René Scharfe
2022-01-13 15:16 ` Ramkumar Ramachandra
2022-01-14 7:47 ` René Scharfe
2022-01-14 8:04 ` Ramkumar Ramachandra
2022-01-18 12:45 ` René Scharfe
2022-01-14 18:42 ` Junio C Hamano
2022-01-13 18:40 ` Junio C Hamano
2022-01-18 12:45 ` [PATCH v2 1/4] bisect--helper: report actual bisect_state() argument on error René Scharfe
2022-01-18 12:46 ` [PATCH v2 2/4] bisect--helper: release strbuf and strvec on run error René Scharfe
2022-01-18 12:46 ` [PATCH v2 3/4] bisect: document run behavior with exit codes 126 and 127 René Scharfe
2022-01-18 12:46 ` [PATCH v2 4/4] bisect--helper: double-check run command on exit code " René Scharfe
2022-01-19 2:36 ` Junio C Hamano
2022-01-19 7:52 ` René Scharfe
2022-02-04 0:42 ` Junio C Hamano
2022-02-04 17:16 ` René Scharfe
2022-02-04 18:16 ` Ramkumar Ramachandra
2022-02-04 19:32 ` Junio C Hamano
2022-02-04 18:09 ` Ramkumar Ramachandra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqilus3ctf.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=r@artagnon.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).