Re: [PATCH v7 00/13] Finish converting git bisect to C part 2

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Christian,

On Thu, 24 Sep 2020, Christian Couder wrote:

> On Wed, Sep 23, 2020 at 11:26 PM Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
> > On Wed, 23 Sep 2020, Johannes Schindelin wrote:
> >
> > > On Wed, 23 Sep 2020, Miriam R. wrote:
> > >
> > > > Applying some of your suggestions related to removing some 'eval' in
> > > > git-bisect shell script, a bug has appeared. It seems it is related to
> > > > a previous code merged before my internship.
> > >
> > > Now you got me curious: what bug did you see?
> >
> > I found your fork and ran the test, and this is the first symptom:
> >
> > -- snip --
> > [...]
> > ++ git bisect skip
> > Bisecting: 1 revision left to test after this (roughly 1 step)
> > [32a594a3fdac2d57cf6d02987e30eec68511498c] Add <4: Ciao for now> into <hello>.
> > ++ git bisect good
> > ++ grep '3082e11d3a0f2edca194c8ce1eb802256e38e75e is the first bad commit' my_bisect_log.txt
> > 3082e11d3a0f2edca194c8ce1eb802256e38e75e is the first bad commit
> > ++ git bisect log
> > ++ git bisect reset
> > Previous HEAD position was 32a594a Add <4: Ciao for now> into <hello>.
> > Switched to branch 'other'
> > ok 22 - bisect skip: add line and then a new test
> >
> > expecting success of 6030.23 'bisect skip and bisect replay':
> >         git bisect replay log_to_replay.txt > my_bisect_log.txt &&
> >         grep "$HASH5 is the first bad commit" my_bisect_log.txt &&
> >         git bisect reset
> >
> > ++ git bisect replay log_to_replay.txt
> > error: update_ref failed for ref 'refs/bisect/bad': cannot update ref 'refs/bisect/bad': trying to write ref 'refs/bisect/bad' with nonexistent object 10006d020000000068986d020000000054f65f00
> > error: last command exited with $?=1
> > not ok 23 - bisect skip and bisect replay
> > #
> > #               git bisect replay log_to_replay.txt > my_bisect_log.txt &&
> > #               grep "$HASH5 is the first bad commit" my_bisect_log.txt &&
> > #               git bisect reset
> > -- snap --
> >
> > So I dug a little bit further (and applied Christian's patch in the
> > meantime), and it turns out that the `eval` has nothing to do with what I
> > originally thought it would be required for: I thought that it wanted to
> > prevent `exit` calls from actually exiting the script.
> >
> > Instead, those `eval` calls are required because the arguments are
> > provided in quoted form. For example, during the execution of t6030.68,
> > the `eval` would expand the call
> >
> >         eval "git bisect--helper --bisect-start $rev $tail"
> >
> > to
> >
> >         git bisect--helper --bisect-start '--term-old' 'term2' '--term-new' 'term1'
>
> Yeah, that was also what I found (along with the bug I sent a patch for).

I suspected that you had found that out, but I really wanted a record on
the Git mailing list about our findings.

It might be a good idea to add a paragraph to the respective patches,
along these lines:

	Note that the `eval` in the changed line of `git-bisect.sh` cannot be
	dropped: it is necessary because the `rev` and the `tail`
	variables may contain multiple, quoted arguments that need to be
	passed to `bisect--helper` (without the quotes, naturally).

> > Therefore, the `eval` really needs to stay in place (also the other `eval`
> > I had originally suggested to remove, for the same reason).
> >
> > I would still recommend appending `|| exit`, even if it just so happens
> > that we will eventually abort when the `bisect--helper` command failed
> > anyway, because the next command will then fail, and abort. But it's
> > cleaner to abort already when this invocation failed rather than relying
> > on that side effect.
>
> Yeah, I think it's a good solution.

Excellent. I think we can actually move forward with the entire patch
series now, not just the first subset, right?

Ciao,
Dscho