'git bisect run' not fully automatic when a merge base must be tested

Hello,

I have encountered a situation where 'git bisect run' is not fully automatic, i.e. it stops before finding the first bad commit with the message: "a merge base must be tested".

Is there a reason why it could not run the provided script on the merge-base that it checks out ?

For context (and a reproducer), I was bisecting the 'git commit --verbose --trailer' regression I reported in [1].

I was running the bisection on a machine without curl installed, and so I was building with 'NO_CURL' and thus needed to cherry-pick my 30bced3a67 (imap-send: add missing "strbuf.h" include under NO_CURL, 2024-02-02) at most steps of the bisection. So I was running this command:

git bisect reset && git bisect start && git bisect bad v2.43.2 && git bisect good v2.42.1 && git bisect run ~/bisect-git.sh

with this script to drive the bisection:

=== ~/bisect-git.sh === #!/bin/bash

git cherry-pick --allow-empty 30bced3a67
if   make -j NO_CURL=1
then
    # run project specific test and report its status
    ~/bisect-trailers.sh
    status=$?
else
    # tell the caller this is untestable
    status=125
fi

# return control exit $status ==== end of ~/bisect-git.sh ===

and this one to reproduce the regression:

=== ~/bisect-trailer.sh === set -e

export PATH="/path/to/git/bin-wrappers/:$PATH"

repo=${TMPDIR:-/tmp}/test-trailers rm -rf "$repo"

unset $(git rev-parse --local-env-vars)

git init "$repo" cd "$repo" date>file git add file export GIT_EDITOR='cat file' git commit --verbose -em "file" --trailer="key: value" > /dev/null git show | \grep -q value === end of ~/bisect-trailer.sh ===

This results in the bisection stopping at:

	HEAD is now at 4a14ccd05d imap-send: add missing "strbuf.h" include under NO_CURL
	Bisecting: a merge base must be tested
	[d57c671a511d885a5cd390e3d6064c37af524a91] treewide: remove unnecessary includes in source files
	bisect run success

with the following bisect log:

git bisect start # status: waiting for both good and bad commits # bad: [efb050becb6bc703f76382e1f1b6273100e6ace3] Git 2.43.2 git bisect bad efb050becb6bc703f76382e1f1b6273100e6ace3 # status: waiting for good commit(s), bad commit known # good: [61a22ddaf0626111193a17ac12f366bd6d167dff] Git 2.42.1 git bisect good 61a22ddaf0626111193a17ac12f366bd6d167dff # good: [5edbcead426056b54286499149244ae4cbf8b5f7] Merge branch 'bc/racy-4gb-files' git bisect good 5edbcead426056b54286499149244ae4cbf8b5f7 # good: [5baedc68b02c1b43b307d436edac702ac3e7b89d] Merge branch 'jk/bisect-reset-fix' into maint-2.43 git bisect good 5baedc68b02c1b43b307d436edac702ac3e7b89d # good: [2873a9686cf59ecbf851cea8c41e6ee545195423] Merge branch 'rs/rebase-use-strvec-pushf' into maint-2.43 git bisect good 2873a9686cf59ecbf851cea8c41e6ee545195423 # bad: [03bc5976514f706889fceea623f35133014ebe78] imap-send: add missing "strbuf.h" include under NO_CURL git bisect bad 03bc5976514f706889fceea623f35133014ebe78 # bad: [9ae3c6dceb187af1ae09649dc5c61bb05a7013d9] imap-send: add missing "strbuf.h" include under NO_CURL git bisect bad 9ae3c6dceb187af1ae09649dc5c61bb05a7013d9 # good: [007488839cabbb5bc6777924ae03c4edeb1b6110] imap-send: add missing "strbuf.h" include under NO_CURL git bisect good 007488839cabbb5bc6777924ae03c4edeb1b6110

This was the first time that I did a bisection with 'git bisect run' that was not fully automated so it threw me off a bit.

I tried it again today and realized that if I modify my ~/bisect-git.sh to use 'git cherry-pick --no-commit --allow-empty' instead, then the bisection runs to completion and finds the bad commit. So my understanding is that cherry-picking a commit during the bisection (without --no-commit) alters the commit graph and might not be the best idea... Looking at the man page the example does use 'git merge --no-commit' so I should have known better.

But the question remains: in general shouldn't 'git bisect run' do everything automatically and not require the user to do something manually ?

And a side note to finish: Initially I did not use 'unset $(git rev-parse --local-env-vars)' in my ~/bisect-trailers.sh, and I was running the bisection in a secondary worktree of my clone of git.git. This did not work at all since the 'git init' and 'git commit --verbose -em "file" --trailer="key: value"' steps were running _in my secondary worktree_ instead of in $TMPDIR, because of how the repository detection works in worktrees and exports some variables (I think...) This was also very confusing and I'm wondering if we should add a note somewhere about that in the documentation, although it seems specific to bisecting git.git...

Cheers, Philippe

[1] https://lore.kernel.org/git/8b4738ad-62cd-789e-712e-bd45a151b4ac@gmail.com/