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

From: Christian Couder <christian.couder@gmail.com>
Date: Dec 4, 2018, 11:04 UTC
Message-ID: <CAP8UFD2xv6SK+qPXKr5hQ0ZctOR5K-BNg1wdBy5=fp2DVBZMHw@mail.gmail.com>
In-Reply-To: <CA+YJQx72dMybGWyzNMUcNcVZnpDTHoaONcC-AQdqt=C_8aEdXg@mail.gmail.com>

On Tue, Dec 4, 2018 at 10:53 AM Lukáš Krejčí <lskrejci@gmail.com> wrote:

>
> Executing git bisect replay reaches a different commit than
> the one that is obtained by running the commands from the bisect log manually.

> $ git bisect replay /var/tmp/git-bisect.log
> We are not bisecting.
> Bisecting: a merge base must be tested
> [d72e90f33aa4709ebecc5005562f52335e106a60] Linux 4.18-rc6

Merge bases are tested only when the good commit is not an ancestor of the bad commit. If this didn't happen when the log was recorded, it shouldn't happen when it is replayed.

Here it seems that this is happening at the beginning of the replay. Perhaps git bisect replay is taking into account the current branch/commit though it shouldn't.

I wonder if this would happen if the current branch/commit has the good commit as an ancestor.

Could you try to check that? And first could you give us the output of:

git merge-base 5b394b2ddf0347bef56e50c69a58773c94343ff3 94710cac0ef4ee177a63b5227664b38c95bbf703