{"thread":{"id":"63164","subject":"RFC: git bisect worktrees ../wk-A:../wk-B","startedAt":"2025-03-19T14:11:52Z","lastAt":"2025-03-21T08:19:22Z","messageCount":2,"participants":["jim.cromie@gmail.com","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"514641","messageId":"CAJfuBxyUvvmevCC7bqLNJM-kTRVtMEhF4rSgf_1OQxezCOLSHg@mail.gmail.com","threadId":"63164","inReplyTo":null,"subject":"RFC: git bisect worktrees ../wk-A:../wk-B","fromName":"","fromEmail":"jim.cromie@gmail.com","sentAt":"2025-03-19T14:11:24Z","receivedAt":"2025-03-19T14:11:52Z","isPatch":false,"sender":{"key":"jim.cromie@gmail.com","avatar":null},"body":"hello all,\n\nit would be super convenient if git bisect was able\nto flip-flop between 2 (or more) worktrees while bisecting.\n\nThis would leave both A, B in re-test-able states,\nallowing detailed forensics on the differences.\n\nif this were a well-known feature, I could imagine that\ntools like rr would be enhanced to exploit it,\ndue to the lure of a tightly controlled A-B test environment,\nmaybe even doing side by side record & replay\nto find where things go differently.\n\nand perhaps:\n\ngit bisect try <commit>   # go with a hunch\n\nthis would check out the commit,\nthen testing would determine good/bad\nsort of the opposite of skip.\n\ngit bisect try HEAD~20 bad [ HEAD ]\n\nhere bisect doesnt pick the next, it follows your hunch\n\nthanks for your consideration,\n~jimc\n"},{"id":"514825","messageId":"xmqqo6xuvlrs.fsf@gitster.g","threadId":"63164","inReplyTo":"CAJfuBxyUvvmevCC7bqLNJM-kTRVtMEhF4rSgf_1OQxezCOLSHg@mail.gmail.com","subject":"Re: RFC: git bisect worktrees ../wk-A:../wk-B","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-03-21T08:19:19Z","receivedAt":"2025-03-21T08:19:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"jim.cromie@gmail.com writes:\n\n> hello all,\n>\n> it would be super convenient if git bisect was able\n> to flip-flop between 2 (or more) worktrees while bisecting.\n>\n> This would leave both A, B in re-test-able states,\n> allowing detailed forensics on the differences.\n\nMany small questions come to mind, including \"why two, not arbitrary\nN?\".\n\nA bit more constructively, I think you should be able to build the\nmachinery around \"git bisect --no-checkout\".  In \"no-checkout\" mode,\nthe bisection machinery is used only to compute which one to try,\nand then you can update your own checkout you choose, which can span\nacross multiple working trees.\n\nAnd that machinery you'd build around \"git bisect --no-checkout\"\nwould be the place to answer those many small questions like \"you\ncan use N worktrees round-robin fashion to keep the last N states\nfor comparison---what should the value of N?\".\n\n> if this were a well-known feature, I could imagine that\n> tools like rr would be enhanced to exploit it,\n\nSo, if you are planning to teach third-party tools and enhance them,\nthe feature for them to exploit already exists, I would say, in the\nform of \"bisect --no-checkout\".\n\n"}]}