Đoàn Trần Công Danh <congdanhqx@xxxxxxxxx> writes:
> On 2022-09-23 22:54:03+0200, Claus Fischer <claus.fischer@xxxxxxxxxxxxxxxx> wrote:
>>
>> Dear Git maintainers,
>>
>> I have looked at the manpage of git bisect but have not found
>> what I need:
>> I would like git bisect not just to report the 'bad' revision
>> within a bunch of text but instead either stop at the first
>> bad revision (the last good will then be HEAD~1) or report
>> it in a scriptable way, i.e.
>>
>> BADHEAD=$(git bisect run --shut-up-and-report-the-bad)
>>
>> Have I overlooked anything?
>
> After running "git bisect run"
> You can take its revisions with:
>
> BADHEAD=$(git rev-parse --verify refs/bisect/bad)
Christian, who invested quite a lot of work in the command (cc'ed),
may have more tricks up his sleeve.
You can also check .git/BISECT_LOG; the value of refs/bisect/bad is
the source of truth, as the final verdict message given by the
command (cf. builtin/bisect--helper.c::bisect_successful() that
reads from "refs/bisect/$bad" which is called when "the first bad
commit" is found by bisect.c::bisect_next_all()).
One thing that may confuse a new user is that the commit HEAD, when
"git bisect" finds the first bad commit, may not be a bad one. You
start from a longer streatch of history (time flows from left to right,
B and G are known bad and good ones, ? are not known)
?---?---?
/ \
-----G---?---?---?---?---?---B
and then go narrowing down by answering "is this one good?"
questions. Answering "Good" paints all its unknown ancestors as
"Good". The final step may look like this, where the sole '?' is
the commit that is checked out to be tested:
G---G---G
/ \
-----G---G---G---?---B---B---B
And the answer to the final step may be "good" or "bad". If it is
"good", then the first bad commit would be its child commit, which
is a merge commit that introduced the badness into the history.
But still, the first bad commit is found at refs/bisect/bad
