Re: first bisection step takes quite a while

From: D. Ben Knoble <ben.knoble@gmail.com>
Date: Feb 24, 2025, 17:27 UTC
Message-ID: <CALnO6CCoD8iRENU+OkCAkKGhiHPVtACZMojAsJbo8=cDYLC_eQ@mail.gmail.com>
In-Reply-To: <CAP8UFD3EpwK3edfBfqRWmcncRFG--Q-yHR=K1wZnDHJs56ZipA@mail.gmail.com>

On Fri, Feb 21, 2025 at 3:25 PM Christian Couder <christian.couder@gmail.com> wrote:

Show 18 quoted lines

>
> On Fri, Feb 21, 2025 at 6:47 PM Junio C Hamano <gitster@pobox.com> wrote:
> >
> > Christian Couder <christian.couder@gmail.com> writes:
> >
> > > Yeah, it seems to me that in practice this is a bit like bisecting on
> > > the first parents first. It would be nice if we had added an option to
> > > bisect on the first parents first, so that we could compare your
> > > improvement and that option.
> >
> > Unless you are talking about something entirely different, I am
> > afraid you are confused.  We added first-parent bisection in mid
> > 2020.
>
> Yeah, I know that. But I don't think there is a mode which performs
> first-parent bisection first and then continues bisecting normally (so
> not only on the first parents). That's why I called it an option that
> does "first parents first" and not just "first parent".

This was also how I read your original reply, and I think it would be a nice addition. It automates something I've done a few times when bisecting in large repos where the good reference is far away in terms of commits, and where automated build+test (bisect run) can be slow.

Essentially
1. bisect with --first-parent to find a bad merge M
2. bisect between M^1 and M^@ (maybe this is the set M^-2, if I'm
reading "git help revisions" correctly?)

with the idea that (1) is fast but coarse (but also helps skip unrelated, potentially bad commits in the merge parents) and (2) is fine-grained but still fast because the set of commits is hopefully small.

(Most readers know the previous justification, I expect, but I figured I would spell it out.)

> Thanks for working on this.

Seconded!

-- 
D. Ben Knoble