public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox•com>
To: jim.cromie@gmail•com
Cc: git@vger•kernel.org
Subject: Re: RFC: git bisect worktrees ../wk-A:../wk-B
Date: Fri, 21 Mar 2025 01:19:19 -0700	[thread overview]
Message-ID: <xmqqo6xuvlrs.fsf@gitster.g> (raw)
In-Reply-To: <CAJfuBxyUvvmevCC7bqLNJM-kTRVtMEhF4rSgf_1OQxezCOLSHg@mail.gmail.com> (jim cromie's message of "Wed, 19 Mar 2025 08:11:24 -0600")

jim.cromie@gmail•com writes:

> 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".


      reply	other threads:[~2025-03-21  8:19 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-19 14:11 RFC: git bisect worktrees ../wk-A:../wk-B jim.cromie
2025-03-21  8:19 ` Junio C Hamano [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqo6xuvlrs.fsf@gitster.g \
    --to=gitster@pobox$(echo .)com \
    --cc=git@vger$(echo .)kernel.org \
    --cc=jim.cromie@gmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox