RFC: git bisect worktrees ../wk-A:../wk-B

jim.cromie@gmail.com· Mar 19, 2025, 14:11 UTC · lore

hello all,

it would be super convenient if git bisect was able to flip-flop between 2 (or more) worktrees while bisecting.

This would leave both A, B in re-test-able states, allowing detailed forensics on the differences.

if this were a well-known feature, I could imagine that tools like rr would be enhanced to exploit it, due to the lure of a tightly controlled A-B test environment, maybe even doing side by side record & replay to find where things go differently.

and perhaps:

git bisect try <commit>   # go with a hunch

this would check out the commit, then testing would determine good/bad sort of the opposite of skip.

git bisect try HEAD~20 bad [ HEAD ]

here bisect doesnt pick the next, it follows your hunch

thanks for your consideration, ~jimc

Junio C Hamano· Mar 21, 2025, 08:19 UTC · re: jim.cromie@gmail.com · lore

Re: RFC: git bisect worktrees ../wk-A:../wk-B

jim.cromie@gmail.com writes:

Show 7 quoted lines

> hello all,
>
> it would be super convenient if git bisect was able
> to flip-flop between 2 (or more) worktrees while bisecting.
>
> This would leave both A, B in re-test-able states,
> allowing detailed forensics on the differences.

Many small questions come to mind, including "why two, not arbitrary N?".

A bit more constructively, I think you should be able to build the machinery around "git bisect --no-checkout". In "no-checkout" mode, the bisection machinery is used only to compute which one to try, and then you can update your own checkout you choose, which can span across multiple working trees.

And that machinery you'd build around "git bisect --no-checkout" would be the place to answer those many small questions like "you can use N worktrees round-robin fashion to keep the last N states for comparison---what should the value of N?".

> if this were a well-known feature, I could imagine that
> tools like rr would be enhanced to exploit it,

So, if you are planning to teach third-party tools and enhance them, the feature for them to exploit already exists, I would say, in the form of "bisect --no-checkout".