On Fri, Feb 21, 2025 at 3:25 PM Christian Couder <christian.couder@xxxxxxxxx> wrote: > > On Fri, Feb 21, 2025 at 6:47 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > > > Christian Couder <christian.couder@xxxxxxxxx> 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
