Re: '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...