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

From: Rubén Justo <rjusto@gmail.com>
Date: Feb 8, 2023, 21:54 UTC
Message-ID: <d95d9505-db32-ebe6-1f23-05f7f00c2922@gmail.com>
In-Reply-To: <xmqqo7q4vir8.fsf@gitster.g>

On 07-feb-2023 21:16:59, Junio C Hamano wrote:

Show 32 quoted lines

> Rubén Justo <rjusto@gmail.com> 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.