From: Phillip Wood <phillip.wood123@gmail.com>
To: Junio C Hamano <gitster@pobox.com>,
Willem Verstraeten <willem.verstraeten@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 2/2] checkout: forbid "-B <branch>" from touching a branch used elsewhere
Date: Thu, 23 Nov 2023 16:33:11 +0000 [thread overview]
Message-ID: <bf848477-b4dd-49d3-8e4b-de0fc3948570@gmail.com> (raw)
In-Reply-To: <xmqqpm01au0w.fsf_-_@gitster.g>
Hi Junio
On 23/11/2023 06:00, Junio C Hamano wrote:
> "git checkout -B <branch> [<start-point>]", being a "forced" version
> of "-b", switches to the <branch>, after optionally resetting its
> tip to the <start-point>, even if the <branch> is in use in another
> worktree, which is somewhat unexpected.
>
> Protect the <branch> using the same logic that forbids "git checkout
> <branch>" from touching a branch that is in use elsewhere.
>
> This is a breaking change that may deserve backward compatibliity
> warning in the Release Notes. The "--ignore-other-worktrees" option
> can be used as an escape hatch if the finger memory of existing
> users depend on the current behaviour of "-B".
I think this change makes sense and I found the implementation here much
easier to understand than a previous attempt at
https://lore.kernel.org/git/20230120113553.24655-1-carenas@gmail.com/
> Reported-by: Willem Verstraeten <willem.verstraeten@gmail.com>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>
> * The documentation might also need updates, but I didn't look at.
This option is documented as an atomic version of
git branch -f <branch> [<start-point>]
git checkout <branch>
However "git branch -f <branch>" will fail if the branch is checked out
in the current worktree whereas "git checkout -B" succeeds. I think
allowing the checkout in that case makes sense for "git checkout -B" but
it does mean that description is not strictly accurate. I'm not sure it
matters that much though.
The documentation for "switch -C" is a bit lacking compared to "checkout
-B" but that is a separate problem.
>
> builtin/checkout.c | 7 +++++++
> t/t2060-switch.sh | 2 ++
> t/t2400-worktree-add.sh | 8 ++++++++
> 3 files changed, 17 insertions(+)
>
> diff --git a/builtin/checkout.c b/builtin/checkout.c
> index b4ab972c5a..8a8ad23e98 100644
> --- a/builtin/checkout.c
> +++ b/builtin/checkout.c
> @@ -1600,6 +1600,13 @@ static int checkout_branch(struct checkout_opts *opts,
> if (new_branch_info->path && !opts->force_detach && !opts->new_branch)
> die_if_switching_to_a_branch_in_use(opts, new_branch_info->path);
>
> + /* "git checkout -B <branch>" */
> + if (opts->new_branch_force) {
> + char *full_ref = xstrfmt("refs/heads/%s", opts->new_branch);
> + die_if_switching_to_a_branch_in_use(opts, full_ref);
> + free(full_ref);
At the moment this is academic as neither of the test scripts changed by
this patch are leak free and so I don't think we need to worry about it
but it raises an interesting question about how we should handle memory
leaks when dying. Leaving the leak when dying means that a test script
that tests an expected failure will never be leak free but using
UNLEAK() would mean we miss a leak being introduced in the successful
case should the call to "free()" ever be removed. We could of course
rename die_if_checked_out() to error_if_checked_out() and return an
error instead of dying but that seems like a lot of churn just to keep
the leak checker happy.
Best Wishes
Phillip
> + }
> +
> if (!new_branch_info->commit && opts->new_branch) {
> struct object_id rev;
> int flag;
> diff --git a/t/t2060-switch.sh b/t/t2060-switch.sh
> index e247a4735b..c91c4db936 100755
> --- a/t/t2060-switch.sh
> +++ b/t/t2060-switch.sh
> @@ -170,8 +170,10 @@ test_expect_success 'switch back when temporarily detached and checked out elsew
> # we test in both worktrees to ensure that works
> # as expected with "first" and "next" worktrees
> test_must_fail git -C wt1 switch shared &&
> + test_must_fail git -C wt1 switch -C shared &&
> git -C wt1 switch --ignore-other-worktrees shared &&
> test_must_fail git -C wt2 switch shared &&
> + test_must_fail git -C wt2 switch -C shared &&
> git -C wt2 switch --ignore-other-worktrees shared
> '
>
> diff --git a/t/t2400-worktree-add.sh b/t/t2400-worktree-add.sh
> index df4aff7825..bbcb2d3419 100755
> --- a/t/t2400-worktree-add.sh
> +++ b/t/t2400-worktree-add.sh
> @@ -126,6 +126,14 @@ test_expect_success 'die the same branch is already checked out' '
> )
> '
>
> +test_expect_success 'refuse to reset a branch in use elsewhere' '
> + (
> + cd here &&
> + test_must_fail git checkout -B newmain 2>actual &&
> + grep "already used by worktree at" actual
> + )
> +'
> +
> test_expect_success SYMLINKS 'die the same branch is already checked out (symlink)' '
> head=$(git -C there rev-parse --git-path HEAD) &&
> ref=$(git -C there symbolic-ref HEAD) &&
next prev parent reply other threads:[~2023-11-23 16:33 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-22 19:08 git checkout -B <branch> lets you checkout a branch that is already checked out in another worktree Inbox Willem Verstraeten
2023-11-23 1:28 ` Junio C Hamano
2023-11-23 5:58 ` Junio C Hamano
2023-11-23 6:00 ` [PATCH 2/2] checkout: forbid "-B <branch>" from touching a branch used elsewhere Junio C Hamano
2023-11-23 16:33 ` Phillip Wood [this message]
2023-11-23 17:09 ` Eric Sunshine
2023-11-24 1:19 ` Junio C Hamano
2023-11-27 1:51 ` Junio C Hamano
2023-11-27 21:31 ` Jeff King
2023-11-30 15:22 ` Phillip Wood
2023-12-04 12:20 ` Willem Verstraeten
2023-12-04 21:06 ` Eric Sunshine
2023-12-08 17:13 ` Junio C Hamano
2024-01-30 12:37 ` Willem Verstraeten
2024-01-30 22:30 ` Junio C Hamano
2023-11-23 22:03 ` git checkout -B <branch> lets you checkout a branch that is already checked out in another worktree Inbox Andy Koppe
2023-11-23 12:12 ` Willem Verstraeten
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=bf848477-b4dd-49d3-8e4b-de0fc3948570@gmail.com \
--to=phillip.wood123@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=phillip.wood@dunelm.org.uk \
--cc=willem.verstraeten@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 NNTP newsgroup(s).