Subject: Re: [PATCH v2] bisect: fix "reset" when branch is checked out elsewhere

From: Rubén Justo <[email-masked]>
Date: Wed, 8 Feb 2023 22:54:53 +0100

On 07-feb-2023 21:16:59, Junio C Hamano wrote:
> Rubén Justo <[email-masked]> writes:
> 
> > No problem.  I am sorry because I don't understand what's worrying you.
> >
> >> that the phrasing of this paragraph is misleading), but isn't it a
> >> good thing if in this sequence:
> >> 
> >>  - I checkout 'main' and start bisecting (BISECT_HEAD says 'main');
> >> 
> >>  - I then checkout 'main' in another worktree; I may even make a
> >>    commit or two, or even rename 'main' to 'master'.
> >> 
> >>  - I finish bisection and "bisect reset" tries to take me back to
> >>    'main', which may notice that 'main' is checked out in the other
> >>    worktree, and fail.
> >> 
> >> the last one failed?  After the above sequence, I now have two
> >> worktrees, both checking out 'main', and it is exactly the situation
> >> the safety valve tries to prevent from occuring, no?
> >
> > We are considering the initial branch (BISECT_START) as a branch checked
> > out _implicitly_ in the worktree that is bisecting.  Doesn't that
> > provide us and the user enough safety?
> 
> If that is a question, then the answer is no.  If that is
> rhetorical, then I just do not see how it gives us any safety.
> 
> In the end, if you allow "bisect reset" to check out 'main' in the
> worktree you used to run bisection, the 'main' branch is checked out
> twice, once there, and another checkout in the other worktree.  That
> is exactly what "git checkout 'main'" in one worktree while 'main'
> is already checked out in another would prevent from happening, no?

Yes, but I still don't understand what you are worried about.

If we compare with "rebase": "git rebase --abort" does checkout back to
the original branch too.  But as "git rebase" is in a more evolved
"builtin transition", and uses reset_head() instead of spawing a new Git
with "checkout", it avoids the "--ignore-other-worktrees".

The safety I'm considering with "git bisect reset" is that while a
branch is being bisected in a worktree, that branch cannot be (without
forcing): checked out in another worktree, deleted or renamed.

And this safety is enough, to me, to alleviate the user from having to
"git bisect reset" to a "safe" place and then "git checkout
--ignore-other-worktrees" to have the BISECT_START branch checked out
again.

Also, note that the aim of this patch is not to introduce a new behavior, but
fix how "git bisect reset" works with multiple worktrees.