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

From: Christian Couder <christian.couder@gmail.com>
Date: Dec 4, 2018, 12:01 UTC
Message-ID: <CAP8UFD3cD5KtvPJK5WkWGVUT6grbL=xL2MV1YWNJGpOjD3uRiQ@mail.gmail.com>
In-Reply-To: <f9f644daa705c78ef348a4a808d88bc01e7bdbd4.camel@gmail.com>

On Tue, Dec 4, 2018 at 12:20 PM Lukáš Krejčí <lskrejci@gmail.com> wrote:

Show 12 quoted lines

>
> 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.)