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 commits. 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://anongit.freedesktop.org/drm/drm 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.kernel.org/pub/scm/linux/kernel/git/tip/tip git bisect good 958f338e96f874a0d29442396d6adf9c1e17aa2d # bad: [2c20443ec221dcb76484b30933593e8ecd836bbd] Merge tag 'acpi-4.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm git bisect bad 2c20443ec221dcb76484b30933593e8ecd836bbd # bad: [c2fc71c9b74c1e87336a27dba1a5edc69d2690f1] Merge tag 'mtd/for-4.19' of git://git.infradead.org/linux-mtd 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.
