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

From: Rubén Justo <rjusto@gmail.com>
Date: Feb 4, 2023, 22:46 UTC
Message-ID: <a66218a3-919d-eca2-1859-41ac02aa38e7@gmail.com>
In-Reply-To: <xmqqzga5b4yz.fsf@gitster.g>

On 26-ene-2023 09:06:28, Junio C Hamano wrote:

Show 27 quoted lines

> > But, and this is what makes me think that "checking out will fail" is the wrong
> > choice for "bisect", while bisecting, with the worktree in a detached HEAD
> > state, the branch to which "bisect reset" will check out back (BISECT_START),
> > is still considered checked out in the working tree:
> >
> > 	$ git checkout -b work
> > 	$ git bisect start HEAD HEAD~3
> > 	... bisect detaches the current worktree ...
> > 	$ git worktree add work
> > 	Preparing worktree (checkout out 'work')
> > 	fatal: 'work' is already checked out at ...
> >
> > So, checking out back to the implicitly checked out branch sounds like it
> > should not fail.
> 
> If that is what you are aiming at, I suspect that the posted patch
> is doing it in a wrong way.  Instead, we should just declare that
> the branch being bisected does not mean the branch cannot be checked
> out elsewhere, so that
> 
> 	$ git worktree add --detach ../another HEAD^0
> 	$ git checkout -b work
> 	$ git bisect start work work~3
>         ... detaches ...
> 	$ git -C ../another checkout work
> 
> should just work, no?

Sorry, I should have been more explicit, I meant: "checking out back to the implicitly checked out branch sounds like it should not fail in the worktree where the user is bisecting".

So, to your question: no, in another worktree should not work without the --ignore-other-worktrees. But

	$ git checkout -b work
	$ git worktree add -f ../another work
	$ git -C ../another bisect start work work~3
	  ... detaches ...
	$ git -C ../another bisect reset

should work.

> So, how about removing the is_worktree_being_bisected() check from
> find_shared_symref(), so that not just "worktree add" and "bisect
> reset", but "checkout" and "switch" are allowed to make the branch
> current even it is being bisected elsewhere?

The devil is in the details: "git branch -m", "git branch -d".

We're not ready to have BISECT_START pointing to a deleted branch, or renaming a branch pointed by it.

Also the inconvenience that, if we allow the user to checkout normally the same branch in another worktree, we are not providing any facility in "git bisect reset" to override the "already checked out". We are forcing the user to "git bisect reset HEAD~0 && git checkout --ignore-other-worktrees ...". Which, to me, sound as an inconvenience.

> 
> That would affect the other topic, I suspect, as well.

I'm not sure. The other topic is somewhat independent of what we decide here.

This series started because the other topic is going to affect "git bisect", not the other way around. But this series can be considered even if the other topic is discarded.

Now, "git bisect reset" with a branch checked out multiple times, works in the first worktree that has the branch checkedout (the main tree is always the first), and fails in the next ones. This is due to a bug the other topic is fixing.

This series aims to make "git bisect reset" to the original branch, work in all worktrees. Independently of the other topic.