Skip to contentSkip to conversation

git-bisect behaves differently when started in equivalent ways

DISCUSSION Christoph Groth 2 participants 2 messages Apr 11, 2022 – Apr 13, 2022

lore
Share & tools
lore
#0 lore raw

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]

#1 lore raw

Hi,

Quoted 2 lines · Christoph Groth

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.