git-bisect behaves differently when started in equivalent ways

git-bisect behaves differently when started in equivalent ways

[Christoph Groth]

Hello,

I found a puzzling behavior with git-bisect for which I was unable to
find any explanation.  Since this might be a bug, I report it here.

cheers
Christoph


What did you do before the bug happened? (Steps to reproduce your issue)

While bisecting a regression caused by a backwards-incompatible change
in the sympy project, I noticed that “git bisect” can behave
differently when started in different but supposedly equivalent ways.

The following complete log demonstrates the issue.

For the first run, I clone the “sympy” repository and start bisect with
“git bisect start” (as shown in the first example of the git bisect
manpage).  I declare a good and a bad commit and am asked to estimate
a specific commit.  I declare this one to be good (which it is for my
particular problem), but this causes git to remark that a commit is
“both good and bad”.

For the second run, I provide the bad and the good commit to git-bisect
start right away.  I am asked to examine the same commit as before to
which I give the same assessment.  This time, git-bisect accepts this.

# Preparation
/tmp% git clone https://github.com/sympy/sympy.git
Cloning into 'sympy'...
(...)
/tmp% cd sympy 
/tmp/sympy% git checkout sympy-1.7.1
Note: switching to 'sympy-1.7.1'.
(...)
HEAD is now at 9e8f62e059 Merge pull request #20592 from oscarbenjamin/pr_latex_filename

# First run
/tmp/sympy% git bisect start
/tmp/sympy% git bisect good
/tmp/sympy% git bisect bad sympy-1.10.1
Bisecting: a merge base must be tested
[da03c3227771953b0dd175b5b2ef65ebb937b0df] Merge pull request #20228 from sidhu1012/perf
/tmp/sympy% git describe
sympy-1.6-2010-gda03c32277
/tmp/sympy% git bisect good
f5bba2a7147ef8a6980ff043e93dd038c14bb9bc was both good and bad

# Second run
/tmp/sympy% git bisect reset
Previous HEAD position was da03c32277 Merge pull request #20228 from sidhu1012/perf
HEAD is now at 9e8f62e059 Merge pull request #20592 from oscarbenjamin/pr_latex_filename
/tmp/sympy% git bisect start sympy-1.10.1 sympy-1.7.1
Bisecting: a merge base must be tested
[da03c3227771953b0dd175b5b2ef65ebb937b0df] Merge pull request #20228 from sidhu1012/perf
/tmp/sympy% git describe
sympy-1.6-2010-gda03c32277
/tmp/sympy% git bisect good
Bisecting: 2606 revisions left to test after this (roughly 11 steps)
[b335cf582f4a789b725cc37822d6eed42c8d9e71] add test and fix space

What did you expect to happen? (Expected behavior)

I expected git-bisect to behave in the same way both times.

What happened instead? (Actual behavior)

One time it complains that a commit is “both good and bad”, one time it
does not.

Anything else you want to add:

I could not find any explanation for the difference.  If it is
intentional I suggest documenting it more clearly.


[System Info]
git version:
git version 2.30.2
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Linux 5.10.0-13-amd64 #1 SMP Debian 5.10.106-1 (2022-03-17) x86_64
compiler info: gnuc: 10.2
libc info: glibc: 2.31
$SHELL (typically, interactive shell): /bin/zsh


[Enabled Hooks]

Re: git-bisect behaves differently when started in equivalent ways

[Christian Couder]

Hi,

On Tue, Apr 12, 2022 at 9:51 PM Christoph Groth
<christoph@grothesque.org> wrote:

> I found a puzzling behavior with git-bisect for which I was unable to
> find any explanation.  Since this might be a bug, I report it here.

Thanks for reporting this strange behavior.

Unfortunately when trying to reproduce, I don't get
"f5bba2a7147ef8a6980ff043e93dd038c14bb9bc was both good and bad" like
you, but the expected:

Bisecting: 2606 revisions left to test after this (roughly 11 steps)
[b335cf582f4a789b725cc37822d6eed42c8d9e71] add test and fix space

You are using Git 2.30.2 which is one year old. Could you try with a
more recent version like 2.35.1?

Best,
Christian.