I have never really made bisect a part of my workflow, but something I believe would work well with just jj is making two workspaces before and after the issue, and iteratively walking their working revisions toward each other. That has the advantage of being able to run both versions simultaneously easily.
You can run the tests on each commit in parallel if you're okay with wasting CPU time to save wall-clock time. git-branchless can speculatively run linear or binary search in parallel up to a user-specified number of jobs [1], and I'd like it add it to jj someday, as it's one of the features I miss most.
(To run the tests in parallel, git-branchless provisions its own worktrees. For binary search, it speculatively executes the search for the potential success and failure cases; when the number of jobs is a power of 2, this partitions the search space evenly.)
For certain applications and bugs it may be helpful to see a version of the application with the bug running side by side with a version without the bug. By "both versions" I meant the versions checked out in both workspaces. See: https://martinvonz.github.io/jj/latest/working-copy/#workspa...
But you don't know in advance whether a given version has the bug, that's kind of the reason for bisecting. Or do you mean you have 3 versions side-by-side: the last-known-bad, last-known-good, next-unknown-to-test?
I mean making two workspace, and iteratively walking them towards each other in the revision tree, until to you cross the revision that introduced the bug (either both instances show the bug or neither does). There isn't really a reason to have three workspaces. If you want to mark where you were so you don't forget, you can just use bookmarks, but really you can just look at the operation log to see where you were.
