Re: [BUG REPORT] Git does not correctly replay bisect log

[Christian Couder <christian.couder@gmail.com>]

On Tue, Dec 4, 2018 at 12:20 PM Lukáš Krejčí <lskrejci@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.)