RE: git bisect enhancement request

["Randall S. Becker" <rsbecker@nexbridge.com>]

On August 14, 2020 6:08 PM, brian m. carlson wrote:
> On 2020-08-14 at 21:11:19, jim.cromie@gmail.com wrote:
> > please teach git bisect how to use 2 separate worktrees for the
> > bisection, toggling between them as bisection progresses, so that the
> > end result is 2 compiled kernels, one broken, one good.
> 
> I'm not sure how such a thing would be implemented.  Git doesn't know until
> after it's checked out the tree whether a revision is good or bad, since usually
> the user needs to tell it (or use git bisect run).  Even if Git alternated between
> the two worktrees in order, that doesn't mean that one of them will end up
> being good, since Git may find the last good revision early on, then continue
> to bisect and find many bad revisions until it determines the right one.
> 
> Can you tell us more about the algorithm you'd like to see here?

I'm wondering more about the requirements on this. Does the bisect manipulate both worktrees at once or separately? Are these worktrees variants on a theme but on different branches (so synchronizing the commits would probably be impractical) - or bisect both workspaces but using different commits as start and end (this should be scriptable)? Does it flip back and forth between the two worktrees doing a bisect in one, then the other (this should be scriptable)? Or is this just to teach git to bisect a worktree in a distinct manner - which, correct me if I'm wrong, I think it already supports.

Or is this more, I have two worktrees on basically the same branch. When bisect happens, one worktree is bisected, tested. If the new code succeeds, and the other worktree is in a failed state, don't bisect the other worktree in the same direction - that's not right, but I think I know your end-state goal: keep bisecting both worktrees until a state change. What that is leading to is really something different, which is that once bisect is done, you know which commit introduced the bug, so set one worktree to the working commit and the other to the broken commit. If that's the case, it's not a toggle, but an end-state operation to set two worktrees to adjacent commits essentially surrounding the introduction point. Is that what you want?

Regards,
Randall

-- Brief whoami:
 NonStop developer since approximately 211288444200000000
 UNIX developer since approximately 421664400
-- In my real life, I talk too much.