mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <>
To: "Rubén Justo" <>
Cc: Git List <>,
	Phillip Wood <>
Subject: Re: [PATCH] bisect: fix "reset" when branch is checked out elsewhere
Date: Thu, 26 Jan 2023 09:06:28 -0800	[thread overview]
Message-ID: <xmqqzga5b4yz.fsf@gitster.g> (raw)
In-Reply-To: <> ("Rubén Justo"'s message of "Thu, 26 Jan 2023 03:18:23 +0100")

Rubén Justo <> writes:

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

I admit I haven't thought things through, but I tend to be
sympathetic to such a declaration.  After all, "bisect" is a
read-only operation as far as the branch you happened to be on when
you started a bisect session is concerned.  Jumping around and
materializing tree states recorded in various commits leading to the
tip of the branch and inspecting them would not change anything on
the branch itself.  And more importantly, the branch being checked
out in another worktree and modified there should not break the
bisection, EXCEPT that the final "git bisect reset" (without
arguments) would fail if the other worktree removed the branch.

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?

That would affect the other topic, I suspect, as well.  It may be a
positive change.  Or are there cases I missed, where the branch
being bisected should not be touched from elsewhere, and we cannot
remove the check from find_shared_symref()?


  reply	other threads:[~2023-01-26 17:07 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 [this message]
2023-01-26 17:13       ` Junio C Hamano
2023-02-04 22:46       ` Rubén Justo
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 \
    --in-reply-to=xmqqzga5b4yz.fsf@gitster.g \ \ \ \ \

* 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).