From: "Rubén Justo" <rjusto@gmail.com>
To: phillip.wood@dunelm.org.uk, Carlo Arenas <carenas@gmail.com>
Cc: git@vger.kernel.org, pclouds@gmail.com, gitster@pobox.com,
Jinwook Jeong <vustthat@gmail.com>,
Eric Sunshine <sunshine@sunshineco.com>,
Phillip Wood <phillip.wood123@gmail.com>
Subject: Re: [PATCH v4] checkout/switch: disallow checking out same branch in multiple worktrees
Date: Sun, 14 May 2023 22:21:21 +0200 [thread overview]
Message-ID: <31ab5d7c-d310-1659-5d56-2fd341c44275@gmail.com> (raw)
In-Reply-To: <a848b7d5-fd40-b043-7ed9-1672f65312e6@dunelm.org.uk>
On 27-ene-2023 14:46:45, Phillip Wood wrote:
> Hi Carlo
>
> On 20/01/2023 22:12, Carlo Arenas wrote:
> > On Fri, Jan 20, 2023 at 7:08 AM Phillip Wood <phillip.wood123@gmail.com> wrote:
> > >
> > > On 20/01/2023 11:35, Carlo Marcelo Arenas Belón wrote:
> > > > Commands `git switch -C` and `git checkout -B` neglect to check whether
> > > > the provided branch is already checked out in some other worktree, as
> > > > shown by the following:
> > > >
> > > > $ git worktree list
> > > > .../foo beefb00f [main]
> > > > $ git worktree add ../other
> > > > Preparing worktree (new branch 'other')
> > > > HEAD is now at beefb00f first
> > > > $ cd ../other
> > > > $ git switch -C main
> > > > Switched to and reset branch 'main'
> > > > $ git worktree list
> > > > .../foo beefb00f [main]
> > > > .../other beefb00f [main]
> > > >
> > > > Fix this problem by teaching `git switch -C` and `git checkout -B` to
> > > > check whether the branch in question is already checked out elsewhere.
> > > >
> > > > Unlike what it is done for `git switch` and `git checkout`, that have
> > > > an historical exception to ignore other worktrees if the branch to
> > > > check is the current one (as required when called as part of other
> > > > tools), the logic implemented is more strict and will require the user
> > > > to invoke the command with `--ignore-other-worktrees` to explicitly
> > > > indicate they want the risky behaviour.
> > > >
> > > > This matches the current behaviour of `git branch -f` and is safer; for
> > > > more details see the tests in t2400.
> > >
> > > As I said before, it would be much easier for everyone else to
> > > understand the changes if you wrote out what they were rather than
> > > saying "look at the tests". I do appreciate the improved test
> > > descriptions though - thanks for that.
> >
> > Apologies on that, I tried to come up with something that would
> > describe the change of behaviour other than the paragraph above and
> > couldn't come out with a better explanation except reading the tests
> > (which I know is complicated by the fact they are interlinked).
> >
> > The behaviour I am changing is also not documented (other than by the
> > test) and might have been added as a quirk to keep the scripted rebase
> > and bisect going when confronted with branches that were checked out
> > in multiple worktrees, and as such might had not be intended for
> > `switch`, and might not be needed anymore either.
> >
> > Using`checkout` for simplicity, but also applies to `switch`,
> >
> > % git worktree list
> > .../base 6a45aba [main]
> > % git worktree add -f ../other main
> > Preparing worktree (checking out 'main')
> > HEAD is now at 6a45aba init
> > % cd ../other
> > % git checkout main
> > Already on 'main'
> > % git checkout -B main
> > fatal: 'main' is already checked out at '.../base'
>
> Thanks for explaining that. If there is no <start-point> given we don't
> reset the branch so it seems a bit harsh to error out here.
We say in the documentation:
+
If `-B` is given, `<new-branch>` is created if it doesn't exist; otherwise, it
is reset. This is the transactional equivalent of
+
------------
$ git branch -f <branch> [<start-point>]
$ git checkout <branch>
------------
+
and, since 55c4a67307 (Prevent force-updating of the current branch,
2011-08-20), we return with error on "git branch -f <current-branch> [...]".
Therefore, when the current branch is checked out in multiple worktrees, it
seems consequent to error on "git checkout -B <current_branch> [...]".
But we want to allow "git checkout -B <current_branch>", without <start-point>,
as a way to say "git reset --keep", see: 39bd6f7261 (Allow checkout -B
<current-branch> to update the current branch, 2011-11-26).
Your suggestion not to error is not only reasonable, but also seems desirable.
Thanks.
next prev parent reply other threads:[~2023-05-14 20:21 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-16 17:28 [PATCH] builtin/checkout: check the branch used in -B with worktrees Carlo Marcelo Arenas Belón
2023-01-16 22:18 ` Eric Sunshine
2023-01-17 0:53 ` Rubén Justo
2023-01-18 5:44 ` Carlo Arenas
2023-01-18 6:15 ` [PATCH v2] checkout/switch: disallow checking out same branch in multiple worktrees Carlo Marcelo Arenas Belón
2023-01-18 6:52 ` Junio C Hamano
2023-01-18 7:58 ` Carlo Arenas
2023-01-18 16:10 ` Junio C Hamano
2023-01-18 22:55 ` Junio C Hamano
2023-01-19 5:53 ` [PATCH v3] " Carlo Marcelo Arenas Belón
2023-01-19 7:23 ` Re* " Junio C Hamano
2023-01-19 7:41 ` Carlo Arenas
2023-01-19 14:21 ` Phillip Wood
2023-01-20 3:10 ` Junio C Hamano
2023-01-20 3:53 ` Carlo Arenas
2023-01-20 4:39 ` Carlo Arenas
2023-01-20 11:35 ` [PATCH v4] " Carlo Marcelo Arenas Belón
2023-01-20 15:08 ` Phillip Wood
2023-01-20 22:12 ` Carlo Arenas
2023-01-27 14:46 ` Phillip Wood
2023-05-14 20:21 ` Rubén Justo [this message]
2023-03-23 0:06 ` Junio C Hamano
2023-03-24 3:49 ` Carlo Arenas
2023-05-14 20:24 ` 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=31ab5d7c-d310-1659-5d56-2fd341c44275@gmail.com \
--to=rjusto@gmail.com \
--cc=carenas@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=pclouds@gmail.com \
--cc=phillip.wood123@gmail.com \
--cc=phillip.wood@dunelm.org.uk \
--cc=sunshine@sunshineco.com \
--cc=vustthat@gmail.com \
/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).