From: Carlo Arenas <carenas@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Phillip Wood" <phillip.wood123@gmail.com>,
git@vger.kernel.org, pclouds@gmail.com,
"Jinwook Jeong" <vustthat@gmail.com>,
"Eric Sunshine" <sunshine@sunshineco.com>,
"Rubén Justo" <rjusto@gmail.com>
Subject: Re: [PATCH v4] checkout/switch: disallow checking out same branch in multiple worktrees
Date: Thu, 23 Mar 2023 20:49:55 -0700 [thread overview]
Message-ID: <CAPUEspj_Bh+LgYLnWfeBdcq_uV5Cbou-7H51GLFjzSa5Qzby9w@mail.gmail.com> (raw)
In-Reply-To: <xmqq355wbaar.fsf@gitster.g>
On Wed, Mar 22, 2023 at 5:06 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Phillip Wood <phillip.wood123@gmail.com> writes:
>
> > Hi Carlo
> > ...
> > 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"....
> > ...
> >> + if (!opts->ignore_other_worktrees && !opts->force_detach &&
> >> + check_branch_path && ref_exists(check_branch_path)) {
> >
> > I think check_branch_path is NULL if opts->ignore_other_worktrees is
> > set so we could maybe lose "!opts->ignore_other_worktrees" here (or
> > possibly below where you set check_branch_path).
> > ...
> >> ...
> >> + if (!opts->ignore_other_worktrees && !check_branch_path && new_branch_info->path)
> >> + check_branch_path = xstrdup(new_branch_info->path);
> >
> > I'm a bit confused what this is doing.
> > ...
> >> +test_expect_success 'allow checkout/reset from the conflicted branch' '
> >
> > I'm not sure what "the conflicted branch" means (it reminds we of
> > merge conflicts). Is this just testing that "checkout -b/B <branch>
> > <start-point>" works?
> > ...
> >> +test_expect_success 'and not die on re-checking out current branch even if conflicted' '
> >
> > I think 'allow re-checking out ...' would be clearer, again I'm not
> > sure what's conflicted here.
> > ...
> >> -test_expect_success 'not die on re-checking out current branch' '
> >> +test_expect_failure 'unless using force without --ignore-other-worktrees' '
> >
> > This test passes for me - what's the reason for changing from
> > test_expect_success to test_expect_failure?
> >
> > Thanks for working on this
>
> are there remaining things
> to be done and issues to be resolved before we can see v5?
it interacted with another branch
(rj/avoid-switching-to-already-used-branch) that was just recently
merged to master.
it also was probably too aggressive as pointed[1] by Phillip after my
explanation of the change of behaviour as quoted:
>> 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. For "git
> checkout -B <branch> <start-point>" when <branch> is checked out in
> another worktree requiring --ignore-other-worktrees makes sense.
I wasn't sure on how to proceed from there, but will come with a v5 to
discuss further.
Carlo
[1] https://lore.kernel.org/git/a848b7d5-fd40-b043-7ed9-1672f65312e6@dunelm.org.uk/
next prev parent reply other threads:[~2023-03-24 3:50 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
2023-03-23 0:06 ` Junio C Hamano
2023-03-24 3:49 ` Carlo Arenas [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAPUEspj_Bh+LgYLnWfeBdcq_uV5Cbou-7H51GLFjzSa5Qzby9w@mail.gmail.com \
--to=carenas@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=pclouds@gmail.com \
--cc=phillip.wood123@gmail.com \
--cc=rjusto@gmail.com \
--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.
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).