Re: [BUG REPORT] Git does not correctly replay bisect log
Christian Couder
Lukáš Krejčí
See Also
Prev Ref 1 Ref 2 Ref 3
2018-12-06 14:43:32 UTC
Hello again,

after looking into this today, I'm not sure if this can be considered a
bug - it's just that I expected Git to check out the exact commit to
test that was there before resetting the bisect. That made me uncertain
whether Git restored the correct state.

When I looked at what Git actually does, it became clear that the
behavior is not incorrect but perhaps a bit surprising.

When Git replays the bisect log, it only updates refs/bisect/bad,
refs/bisect/good-*, refs/bisect/skip-* and reconstructs the log in
.git/BISECT_LOG. After that check_good_are_ancestors_of_bad() verifies
that all good commits are ancestors of the bad commit, and if not, the
message "Bisecting: a merge base must be tested" is printed and the
branch is switched to the merge base of the bad and all the good

Basically, some state is lost because Git "forgot" the first good
commit from the log already was an ancestor of the first bad one.
In other words, it's as if I just started the bisect with the following
commands and just pasted the whole bisect log to .git/BISECT_LOG:

$ git bisect start
$ git bisect good 94710cac0ef4ee177a63b5227664b38c95bbf703
$ git bisect good 958f338e96f874a0d29442396d6adf9c1e17aa2d
$ git bisect bad 1b0d274523df5ef1caedc834da055ff721e4d4f0
Bisecting: a merge base must be tested
[1e4b044d22517cae7047c99038abb444423243ca] Linux 4.18-rc4

(here's the full bisect log again for reference)
git bisect start
# bad: [5b394b2ddf0347bef56e50c69a58773c94343ff3] Linux 4.19-rc1
git bisect bad 5b394b2ddf0347bef56e50c69a58773c94343ff3
# good: [94710cac0ef4ee177a63b5227664b38c95bbf703] Linux 4.18
git bisect good 94710cac0ef4ee177a63b5227664b38c95bbf703
# bad: [54dbe75bbf1e189982516de179147208e90b5e45] Merge tag 'drm-next-2018-08-15' of git://
git bisect bad 54dbe75bbf1e189982516de179147208e90b5e45
# bad: [0a957467c5fd46142bc9c52758ffc552d4c5e2f7] x86: i8259: Add missing include file
git bisect bad 0a957467c5fd46142bc9c52758ffc552d4c5e2f7
# good: [958f338e96f874a0d29442396d6adf9c1e17aa2d] Merge branch 'l1tf-final' of git://
git bisect good 958f338e96f874a0d29442396d6adf9c1e17aa2d
# bad: [2c20443ec221dcb76484b30933593e8ecd836bbd] Merge tag 'acpi-4.19-rc1' of git://
git bisect bad 2c20443ec221dcb76484b30933593e8ecd836bbd
# bad: [c2fc71c9b74c1e87336a27dba1a5edc69d2690f1] Merge tag 'mtd/for-4.19' of git://
git bisect bad c2fc71c9b74c1e87336a27dba1a5edc69d2690f1
# bad: [b86d865cb1cae1e61527ea0b8977078bbf694328] blkcg: Make blkg_root_lookup() work for queues in bypass mode
git bisect bad b86d865cb1cae1e61527ea0b8977078bbf694328
# bad: [1b0d274523df5ef1caedc834da055ff721e4d4f0] nvmet: don't use uuid_le type
git bisect bad 1b0d274523df5ef1caedc834da055ff721e4d4f0

And indeed, marking the merge base as good switches to the correct
commit after the bisect. Marking it as bad will fail, so at least you
can't make a mistake after replaying the bisect log:
$ git bisect bad
The merge base 1e4b044d22517cae7047c99038abb444423243ca is bad.
This means the bug has been fixed between 1e4b044d22517cae7047c99038abb444423243ca and [94710cac0ef4ee177a63b5227664b38c95bbf703 958f338e96f874a0d29442396d6adf9c1e17aa2d].

Once again, I'm sorry for the noise. I guess it wasn't clear from the
man page that something like this could happen and that made me think
that this was a bug.