git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Rubén Justo" <rjusto@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Git List <git@vger.kernel.org>,
	Phillip Wood <phillip.wood@dunelm.org.uk>
Subject: Re: [PATCH v2] bisect: fix "reset" when branch is checked out elsewhere
Date: Wed, 8 Feb 2023 22:54:53 +0100	[thread overview]
Message-ID: <d95d9505-db32-ebe6-1f23-05f7f00c2922@gmail.com> (raw)
In-Reply-To: <xmqqo7q4vir8.fsf@gitster.g>


On 07-feb-2023 21:16:59, Junio C Hamano wrote:
> 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.

  reply	other threads:[~2023-02-08 21:55 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
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 [this message]
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=d95d9505-db32-ebe6-1f23-05f7f00c2922@gmail.com \
    --to=rjusto@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=phillip.wood@dunelm.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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

	https://80x24.org/mirrors/git.git

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