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@xxxxxxxxx/
