Re: [PATCH v5 0/2] bisect: add --reset-when-found to leave when done

"Harald Nordgren via GitGitGadget" <[email protected]> writes:

> Add a --reset-when-found option to git bisect that resets the bisect session
> when culprit is found.
>
> Changes in v5:
>
>  * Move automatic reset handling to cmd_bisect() after subcommand resources
>    are closed.
>  * Propagate the first-bad commit OID from bisect_next_all() and remove
>    defer_reset plumbing.
>  * Separate checkout from state cleanup in bisect_reset(), and use bool for
>    its quiet flag.

I know I suggested the second one, but is it really needed?  The
only reason the "first bad commit" is needed is because we may need
to reset to it when --reset-when-done is in effect, but before that
reset happens, we can look at refs/bisect/bad to find it out, and if
that is the case, there is already a mechanism for the next-all to
tell later code what that first bad commit is already.

If it make the patch series a lot smaller to take advantage of that
fact, that would be superb.

I also do not understand exactly why we need both reset_when_found
and reset_when_found_arg_seen.  If we initialize the former to a
"not set" value that command line argument or the state file can
never set to, then wouldn't it make the latter unnecessary?