On Thu, Dec 6, 2018 at 6:30 PM Lukáš Krejčí wrote:
>
> I am talking about `git bisect replay`. The shell script, as far as I
> can see, only updates the references (ref/bisect/*) and never checks if
> the revisions marked as 'good' are ancestors of the 'bad' one.
> Therefore,
On Thu, 2018-12-06 at 17:31 +0100, Christian Couder wrote:
> > 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
Hi,
On Thu, Dec 6, 2018 at 3:43 PM Lukáš Krejčí wrote:
>
> 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
>
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
On Tue, 2018-12-04 at 13:01 +0100, Christian Couder wrote:
> 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
>
I placed the following
On Tue, Dec 4, 2018 at 12:20 PM Lukáš Krejčí 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
> >
(I'm sorry about the formatting, here's the message again.)
Executing git bisect replay reaches a different commit than
the one that is obtained by running the commands from the bisect log manually.
Distribution: Arch Linux
git: 2.19.2-1
perl: 5.28.1-1
pcre2: 10.32-1
expat: 2.2.6-1
perl-error:
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
On Tue, Dec 4, 2018 at 10:53 AM Lukáš Krejčí 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
Executing git bisect replay reaches a different commit than
the one that is obtained by running the commands from the bisect log manually.
Distribution: Arch Linux
git: 2.19.2-1
perl: 5.28.1-1
pcre2: 10.32-1
expat: 2.2.6-1
perl-error: 0.17027-1
grep: 3.1-2
bash: 4.4.023-1
no system
10 matches
Mail list logo
