mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Rubén Justo" <>
To: Junio C Hamano <>
Cc: Git List <>,
	Phillip Wood <>
Subject: Re: [PATCH] bisect: fix "reset" when branch is checked out elsewhere
Date: Sat, 4 Feb 2023 23:46:47 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <xmqqzga5b4yz.fsf@gitster.g>

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

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

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

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

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.

  parent reply	other threads:[~2023-02-04 22:47 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-22  1:38 [PATCH] bisect: fix "reset" when branch is checked out elsewhere Rubén Justo
2023-01-23  2:01 ` Junio C Hamano
2023-01-26  2:18   ` Rubén Justo
2023-01-26 17:06     ` Junio C Hamano
2023-01-26 17:13       ` Junio C Hamano
2023-02-04 22:46       ` Rubén Justo [this message]
2023-02-06 19:04         ` Junio C Hamano
2023-02-04 22:57 ` [PATCH v2] " Rubén Justo
2023-02-06 22:29   ` Junio C Hamano
2023-02-08  0:30     ` Rubén Justo
2023-02-08  5:16       ` Junio C Hamano
2023-02-08 21:54         ` Rubén Justo
2023-02-15  4:52   ` Eric Sunshine
2023-02-15 22:20     ` Rubén Justo
2023-02-20 22:53   ` [PATCH v3] " Rubén Justo

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:

  List information:

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

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).