On Tue, Dec 4, 2018 at 12:20 PM Lukáš Krejčí <lskre...@gmail.com> wrote: > > On Tue, 2018-12-04 at 12:04 +0100, Christian Couder wrote: > > > > Could you try to check that? And first could you give us the output of: > > > > git merge-base 5b394b2ddf0347bef56e50c69a58773c94343ff3 > > 94710cac0ef4ee177a63b5227664b38c95bbf703 > > $ git merge-base 5b394b2ddf0347bef56e50c69a58773c94343ff3 > 94710cac0ef4ee177a63b5227664b38c95bbf703 > 94710cac0ef4ee177a63b5227664b38c95bbf703 > $ git log -1 --format=oneline 94710cac0ef4ee177a63b5227664b38c95bbf703 > 94710cac0ef4ee177a63b5227664b38c95bbf703 (tag: v4.18) Linux 4.18
94710cac0ef4ee177a63b5227664b38c95bbf703 is the good commit that was initially given. This means that the good commit 94710cac0ef4ee177a63b5227664b38c95bbf703 is an ancestor of the bad commit 5b394b2ddf0347bef56e50c69a58773c94343ff3 i and there should be no reason to test a merge base when replaying. After testing on my machine, it seems that the problem is not happening at the beginning of the replay. To debug I think it would be interesting to see the output of the following commands just before we get different results: git for-each-ref 'refs/bisect/*' and git log -1 --format=oneline in the case we are using `git bisect replay` and in the case we are running the commands from the bisect log manually. (You might need to temporarily remove the last command from the bisect log to do that.)
