{"thread":{"id":"64143","subject":"[PATCH 0/3] extend --ignore-other-worktrees to 'rebase', add hints","startedAt":"2025-09-13T14:14:50Z","lastAt":"2025-09-19T14:13:28Z","messageCount":20,"participants":["Gabriel Scherer","Ben Knoble","Kristoffer Haugsbakk","Junio C Hamano","Phillip Wood"],"isPatch":true,"patchVersion":1,"patchTotal":3},"messages":[{"id":"526243","messageId":"20250913141327.2775228-1-gabriel.scherer@inria.fr","threadId":"64143","inReplyTo":null,"subject":"[PATCH 0/3] extend --ignore-other-worktrees to 'rebase', add hints","fromName":"Gabriel Scherer","fromEmail":"gabriel.scherer@inria.fr","sentAt":"2025-09-13T14:13:17Z","receivedAt":"2025-09-13T14:14:50Z","isPatch":true,"sender":{"key":"gabriel.scherer@inria.fr","avatar":null},"body":"The old 'workdir' contribution script was removed from git upstream in May\n2025, as it is largely superseded by the 'worktree' command.\n\nOne significant difference between the old script and the command is that\n'git' refuses to checkout or rebase branches that are already checked out in\nanother worktree. My understanding of the reasoning is that users may be\nsurprised when a clean worktree becomes dirty as its index is changed from\nanother worktree. However, this safety net adds a mental burden to worktree\nusers, as they have to keep the other worktrees in mind when moving\nbranches. Old goats like me who are used to the old 'workdir' script find\nthis restriction somewhat painful.\n\nSee the discussion thread\n  https://lore.kernel.org/git/5580aa89-09f1-426e-8483-c99481c998ab@gmail.com/\nabout this transition.\n\nThe present patch series tries to provide a smoother migration path for\nsupporters of worktree independence:\n\n - when 'checkout' refuses because the branch is used in another worktree,\n   display a 'hint' that mentions the possibility of using '--detach'\n   instead, and the '--ignore-other-worktrees' option to proceed anyway.\n\n - add support for '--ignore-other-worktrees' in 'rebase' as well, with\n   a similar hint.\n\nIn the future I would be interested in adding an option\n'branch.ignoreOtherWorktrees' to be able to ignore other worktrees globally.\n\nNote: this is my first experience submitting a patch to the Git project, so\nI apologize in advance for any mishap and welcome beginner-level feedback.\n\nCc: Junio C Hamano <gitster@pobox.com>\nCc: D. Ben Knoble <ben.knoble@gmail.com>\nCc: Phillip Wood <phillip.wood@dunelm.org.uk>\n\nSigned-off-by: Gabriel Scherer <gabriel.scherer@inria.fr>\n\nGabriel.Scherer (3):\n  checkout: provide hint when failing due to another worktree\n  rebase: support --ignore-other-worktrees\n  rebase: hint when failing on branch used by another worktree\n\n Documentation/config/advice.adoc |  3 +++\n Documentation/git-rebase.adoc    |  6 ++++++\n advice.c                         |  1 +\n advice.h                         |  1 +\n branch.c                         | 13 +++++++++++--\n branch.h                         |  4 ++++\n builtin/checkout.c               | 12 ++++++++++--\n builtin/rebase.c                 | 19 ++++++++++++++++++-\n t/t3400-rebase.sh                |  4 +++-\n 9 files changed, 57 insertions(+), 6 deletions(-)\n\n-- \n2.51.0\n\n"},{"id":"526244","messageId":"20250913141327.2775228-2-gabriel.scherer@inria.fr","threadId":"64143","inReplyTo":"20250913141327.2775228-1-gabriel.scherer@inria.fr","subject":"[PATCH 1/3] checkout: provide hint when failing due to another worktree","fromName":"Gabriel Scherer","fromEmail":"gabriel.scherer@inria.fr","sentAt":"2025-09-13T14:13:18Z","receivedAt":"2025-09-13T14:14:52Z","isPatch":true,"sender":{"key":"gabriel.scherer@inria.fr","avatar":null},"body":"From: \"Gabriel.Scherer\" <gabriel.scherer@inria.fr>\n\nWhen checkout/switch fails because the target branch is already used\nby another worktree, we now hint that the user could use --detach or\n--ignore-other-worktrees.\n\nNote: this error can also happen on rebase, which unfortunately does\nnot support --ignore-other-worktrees. We do not show advice in this\ncase, and leave 'rebase --ignore-other-worktrees' to future work.\n\nSigned-off-by: Gabriel Scherer <gabriel.scherer@inria.fr>\n---\n Documentation/config/advice.adoc |  3 +++\n advice.c                         |  1 +\n advice.h                         |  1 +\n branch.c                         | 13 +++++++++++--\n branch.h                         |  4 ++++\n builtin/checkout.c               | 12 ++++++++++--\n 6 files changed, 30 insertions(+), 4 deletions(-)\n\ndiff --git a/Documentation/config/advice.adoc b/Documentation/config/advice.adoc\nindex 257db58918..9ee64f44ea 100644\n--- a/Documentation/config/advice.adoc\n+++ b/Documentation/config/advice.adoc\n@@ -27,6 +27,9 @@ all advice messages.\n \t\tShown when a fetch refspec for multiple remotes maps to\n \t\tthe same remote-tracking branch namespace and causes branch\n \t\ttracking set-up to fail.\n+\tbranchUsedInOtherWorktree::\n+\t\tShown when the user attemps to switch to a branch\n+\t\tthat is already checked out in another worktree.\n \tcheckoutAmbiguousRemoteBranchName::\n \t\tShown when the argument to\n \t\tlinkgit:git-checkout[1] and linkgit:git-switch[1]\ndiff --git a/advice.c b/advice.c\nindex e5f0ff8449..5c9b763472 100644\n--- a/advice.c\n+++ b/advice.c\n@@ -50,6 +50,7 @@ static struct {\n \t[ADVICE_AMBIGUOUS_FETCH_REFSPEC]\t\t= { \"ambiguousFetchRefspec\" },\n \t[ADVICE_AM_WORK_DIR] \t\t\t\t= { \"amWorkDir\" },\n \t[ADVICE_CHECKOUT_AMBIGUOUS_REMOTE_BRANCH_NAME] \t= { \"checkoutAmbiguousRemoteBranchName\" },\n+\t[ADVICE_BRANCH_USED_IN_OTHER_WORKTREE]\t\t= { \"branchUsedInOtherWorktree\" },\n \t[ADVICE_COMMIT_BEFORE_MERGE]\t\t\t= { \"commitBeforeMerge\" },\n \t[ADVICE_DEFAULT_BRANCH_NAME]\t\t\t= { \"defaultBranchName\" },\n \t[ADVICE_DETACHED_HEAD]\t\t\t\t= { \"detachedHead\" },\ndiff --git a/advice.h b/advice.h\nindex 727dcecf4a..6b11df945b 100644\n--- a/advice.h\n+++ b/advice.h\n@@ -16,6 +16,7 @@ enum advice_type {\n \tADVICE_ADD_IGNORED_FILE,\n \tADVICE_AMBIGUOUS_FETCH_REFSPEC,\n \tADVICE_AM_WORK_DIR,\n+\tADVICE_BRANCH_USED_IN_OTHER_WORKTREE,\n \tADVICE_CHECKOUT_AMBIGUOUS_REMOTE_BRANCH_NAME,\n \tADVICE_COMMIT_BEFORE_MERGE,\n \tADVICE_DEFAULT_BRANCH_NAME,\ndiff --git a/branch.c b/branch.c\nindex 26be358347..76aa2cbf44 100644\n--- a/branch.c\n+++ b/branch.c\n@@ -844,7 +844,7 @@ void remove_branch_state(struct repository *r, int verbose)\n \tremove_merge_branch_state(r);\n }\n \n-void die_if_checked_out(const char *branch, int ignore_current_worktree)\n+int die_message_if_checked_out(const char *branch, int ignore_current_worktree)\n {\n \tstruct worktree **worktrees = get_worktrees();\n \n@@ -854,10 +854,19 @@ void die_if_checked_out(const char *branch, int ignore_current_worktree)\n \n \t\tif (is_shared_symref(worktrees[i], \"HEAD\", branch)) {\n \t\t\tskip_prefix(branch, \"refs/heads/\", &branch);\n-\t\t\tdie(_(\"'%s' is already used by worktree at '%s'\"),\n+\t\t\treturn die_message(\n+\t\t\t\t_(\"'%s' is already used by worktree at '%s'\"),\n \t\t\t\tbranch, worktrees[i]->path);\n \t\t}\n \t}\n \n \tfree_worktrees(worktrees);\n+\treturn 0;\n+}\n+\n+void die_if_checked_out(const char *branch, int ignore_current_worktree)\n+{\n+\tint code = die_message_if_checked_out(branch, ignore_current_worktree);\n+\tif (code)\n+\t\texit(code);\n }\ndiff --git a/branch.h b/branch.h\nindex ec2f35fda4..84c81508e9 100644\n--- a/branch.h\n+++ b/branch.h\n@@ -155,4 +155,8 @@ int read_branch_desc(struct strbuf *, const char *branch_name);\n  */\n void die_if_checked_out(const char *branch, int ignore_current_worktree);\n \n+/* Similar to 'die_if_checked_out' above, but returns a non-zero\n+   error code after printing the message instead of dying immediately. */\n+int die_message_if_checked_out(const char *branch, int ignore_current_worktree);\n+\n #endif\ndiff --git a/builtin/checkout.c b/builtin/checkout.c\nindex f9453473fe..e4b78f4a05 100644\n--- a/builtin/checkout.c\n+++ b/builtin/checkout.c\n@@ -1582,8 +1582,16 @@ static void die_if_switching_to_a_branch_in_use(struct checkout_opts *opts,\n \t\treturn;\n \thead_ref = refs_resolve_refdup(get_main_ref_store(the_repository),\n \t\t\t\t       \"HEAD\", 0, NULL, &flags);\n-\tif (head_ref && (!(flags & REF_ISSYMREF) || strcmp(head_ref, full_ref)))\n-\t\tdie_if_checked_out(full_ref, 1);\n+\tif (head_ref && (!(flags & REF_ISSYMREF) || strcmp(head_ref, full_ref))) {\n+\t\tint code = die_message_if_checked_out(full_ref, 1);\n+\t\tif (code) {\n+\t\t\tadvise_if_enabled(\n+\t\t\t\tADVICE_BRANCH_USED_IN_OTHER_WORKTREE,\n+\t\t\t\t_(\"Use --detach to avoid this restriction,\\n\"\n+\t\t\t\t\"or --ignore-other-worktrees to ignore it.\"));\n+\t\t\texit(code);\n+\t\t}\n+\t}\n \tfree(head_ref);\n }\n \n-- \n2.51.0\n\n"},{"id":"526245","messageId":"20250913141327.2775228-3-gabriel.scherer@inria.fr","threadId":"64143","inReplyTo":"20250913141327.2775228-1-gabriel.scherer@inria.fr","subject":"[PATCH 2/3] rebase: support --ignore-other-worktrees","fromName":"Gabriel Scherer","fromEmail":"gabriel.scherer@inria.fr","sentAt":"2025-09-13T14:13:19Z","receivedAt":"2025-09-13T14:14:54Z","isPatch":true,"sender":{"key":"gabriel.scherer@inria.fr","avatar":null},"body":"From: \"Gabriel.Scherer\" <gabriel.scherer@inria.fr>\n\nrebase can currently fail if the branch to rebase is checked out in\nanother worktree, and there is no way for users to override this\nerror. We add support for the '--ignore-other-worktrees' option of\n'checkout'.\n\nSigned-off-by: Gabriel Scherer <gabriel.scherer@inria.fr>\n---\n Documentation/git-rebase.adoc |  6 ++++++\n builtin/rebase.c              | 11 ++++++++++-\n t/t3400-rebase.sh             |  4 +++-\n 3 files changed, 19 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/git-rebase.adoc b/Documentation/git-rebase.adoc\nindex 005caf6164..b703d4056e 100644\n--- a/Documentation/git-rebase.adoc\n+++ b/Documentation/git-rebase.adoc\n@@ -305,6 +305,12 @@ see the `--empty` flag.\n +\n See also INCOMPATIBLE OPTIONS below.\n \n+--ignore-other-worktrees::\n+\tBy default, `git rebase` refuses when the branch to rebase is\n+\talready checked out or otherwise in use by another\n+\tworktree. With this option, other worktrees are ignored and\n+\tthe rebase proceeds anyway.\n+\n --reapply-cherry-picks::\n --no-reapply-cherry-picks::\n \tReapply all clean cherry-picks of any upstream commit instead\ndiff --git a/builtin/rebase.c b/builtin/rebase.c\nindex 3c85768d29..7a57ebd852 100644\n--- a/builtin/rebase.c\n+++ b/builtin/rebase.c\n@@ -128,6 +128,7 @@ struct rebase_options {\n \tstruct strbuf git_format_patch_opt;\n \tint reschedule_failed_exec;\n \tint reapply_cherry_picks;\n+\tint ignore_other_worktrees;\n \tint fork_point;\n \tint update_refs;\n \tint config_autosquash;\n@@ -146,6 +147,7 @@ struct rebase_options {\n \t\t.git_format_patch_opt = STRBUF_INIT,\t\\\n \t\t.fork_point = -1,\t\t\t\\\n \t\t.reapply_cherry_picks = -1,             \\\n+\t\t.ignore_other_worktrees = -1,           \\\n \t\t.allow_empty_message = 1,               \\\n \t\t.autosquash = -1,                       \\\n \t\t.rebase_merges = -1,                    \\\n@@ -1234,6 +1236,8 @@ int cmd_rebase(int argc,\n \t\t\t N_(\"automatically re-schedule any `exec` that fails\")),\n \t\tOPT_BOOL(0, \"reapply-cherry-picks\", &options.reapply_cherry_picks,\n \t\t\t N_(\"apply all changes, even those already present upstream\")),\n+\t\tOPT_BOOL(0, \"ignore-other-worktrees\", &options.ignore_other_worktrees,\n+\t\t\t N_(\"do not check if another worktree is using the branch to rebase\")),\n \t\tOPT_END(),\n \t};\n \tint i;\n@@ -1580,6 +1584,10 @@ int cmd_rebase(int argc,\n \t\t\t(options.flags & REBASE_INTERACTIVE_EXPLICIT);\n \t}\n \n+\tif (options.ignore_other_worktrees == -1) {\n+\t\toptions.ignore_other_worktrees = 0;\n+\t}\n+\n \tif (options.type == REBASE_UNSPECIFIED) {\n \t\tif (!strcmp(options.default_backend, \"merge\"))\n \t\t\toptions.type = REBASE_MERGE;\n@@ -1679,7 +1687,8 @@ int cmd_rebase(int argc,\n \t\tstrbuf_reset(&buf);\n \t\tstrbuf_addf(&buf, \"refs/heads/%s\", branch_name);\n \t\tif (!refs_read_ref(get_main_ref_store(the_repository), buf.buf, &branch_oid)) {\n-\t\t\tdie_if_checked_out(buf.buf, 1);\n+\t\t\tif (!options.ignore_other_worktrees)\n+\t\t\t\tdie_if_checked_out(buf.buf, 1);\n \t\t\toptions.head_name = xstrdup(buf.buf);\n \t\t\toptions.orig_head =\n \t\t\t\tlookup_commit_object(the_repository,\ndiff --git a/t/t3400-rebase.sh b/t/t3400-rebase.sh\nindex c0c00fbb7b..08448b4d4e 100755\n--- a/t/t3400-rebase.sh\n+++ b/t/t3400-rebase.sh\n@@ -407,7 +407,9 @@ test_expect_success 'switch to branch checked out elsewhere fails' '\n \t# we test in both worktrees to ensure that works\n \t# as expected with \"first\" and \"next\" worktrees\n \ttest_must_fail git -C wt1 rebase shared shared &&\n-\ttest_must_fail git -C wt2 rebase shared shared\n+\ttest_must_fail git -C wt2 rebase shared shared &&\n+        # with --ignore-other-worktrees the rebase succeeds\n+\tgit -C wt1 rebase --ignore-other-worktrees shared shared\n '\n \n test_expect_success 'switch to branch not checked out' '\n-- \n2.51.0\n\n"},{"id":"526246","messageId":"20250913141327.2775228-4-gabriel.scherer@inria.fr","threadId":"64143","inReplyTo":"20250913141327.2775228-1-gabriel.scherer@inria.fr","subject":"[PATCH 3/3] rebase: hint when failing on branch used by another worktree","fromName":"Gabriel Scherer","fromEmail":"gabriel.scherer@inria.fr","sentAt":"2025-09-13T14:13:20Z","receivedAt":"2025-09-13T14:14:56Z","isPatch":true,"sender":{"key":"gabriel.scherer@inria.fr","avatar":null},"body":"From: \"Gabriel.Scherer\" <gabriel.scherer@inria.fr>\n\nSigned-off-by: Gabriel Scherer <gabriel.scherer@inria.fr>\n---\n builtin/rebase.c | 12 ++++++++++--\n 1 file changed, 10 insertions(+), 2 deletions(-)\n\ndiff --git a/builtin/rebase.c b/builtin/rebase.c\nindex 7a57ebd852..05c86117fc 100644\n--- a/builtin/rebase.c\n+++ b/builtin/rebase.c\n@@ -9,6 +9,7 @@\n \n #include \"builtin.h\"\n \n+#include \"advice.h\"\n #include \"abspath.h\"\n #include \"environment.h\"\n #include \"gettext.h\"\n@@ -1687,8 +1688,15 @@ int cmd_rebase(int argc,\n \t\tstrbuf_reset(&buf);\n \t\tstrbuf_addf(&buf, \"refs/heads/%s\", branch_name);\n \t\tif (!refs_read_ref(get_main_ref_store(the_repository), buf.buf, &branch_oid)) {\n-\t\t\tif (!options.ignore_other_worktrees)\n-\t\t\t\tdie_if_checked_out(buf.buf, 1);\n+\t\t\tif (!options.ignore_other_worktrees) {\n+\t\t\t\tint code = die_message_if_checked_out(buf.buf, 1);\n+\t\t\t\tif (code) {\n+\t\t\t\t\tadvise_if_enabled(\n+\t\t\t\t\t\tADVICE_BRANCH_USED_IN_OTHER_WORKTREE,\n+\t\t\t\t\t\t_(\"Use --ignore-other-worktrees to proceed anyway.\"));\n+\t\t\t\t\texit(code);\n+\t\t\t\t}\n+\t\t\t}\n \t\t\toptions.head_name = xstrdup(buf.buf);\n \t\t\toptions.orig_head =\n \t\t\t\tlookup_commit_object(the_repository,\n-- \n2.51.0\n\n"},{"id":"526255","messageId":"F7295141-49F5-4013-911A-7730C130F8CC@gmail.com","threadId":"64143","inReplyTo":"20250913141327.2775228-1-gabriel.scherer@inria.fr","subject":"Re: [PATCH 0/3] extend --ignore-other-worktrees to 'rebase', add hints","fromName":"Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2025-09-13T19:30:42Z","receivedAt":"2025-09-13T19:30:54Z","isPatch":true,"sender":{"key":"ben.knoble@gmail.com","avatar":"https://avatars.githubusercontent.com/u/22802209?v=4"},"body":"\n> Le 13 sept. 2025 à 10:13, Gabriel Scherer <gabriel.scherer@inria.fr> a écrit :\n> \n> The old 'workdir' contribution script was removed from git upstream in May\n> 2025, as it is largely superseded by the 'worktree' command.\n> \n> One significant difference between the old script and the command is that\n> 'git' refuses to checkout or rebase branches that are already checked out in\n> another worktree. My understanding of the reasoning is that users may be\n> surprised when a clean worktree becomes dirty as its index is changed from\n> another worktree. However, this safety net adds a mental burden to worktree\n> users, as they have to keep the other worktrees in mind when moving\n> branches. Old goats like me who are used to the old 'workdir' script find\n> this restriction somewhat painful.\n> \n> See the discussion thread\n>  https://lore.kernel.org/git/5580aa89-09f1-426e-8483-c99481c998ab@gmail.com/\n> about this transition.\n> \n> The present patch series tries to provide a smoother migration path for\n> supporters of worktree independence:\n> \n> - when 'checkout' refuses because the branch is used in another worktree,\n>   display a 'hint' that mentions the possibility of using '--detach'\n>   instead, and the '--ignore-other-worktrees' option to proceed anyway.\n> \n> - add support for '--ignore-other-worktrees' in 'rebase' as well, with\n>   a similar hint.\n> \n> In the future I would be interested in adding an option\n> 'branch.ignoreOtherWorktrees' to be able to ignore other worktrees globally.\n> \n> Note: this is my first experience submitting a patch to the Git project, so\n> I apologize in advance for any mishap and welcome beginner-level feedback.\n\nI’m eager to see further reviews, but nothing I saw in this series stuck out as a major problem. I saw we updated the rebase test cases; should we add some more for checkout or worktree?"},{"id":"526256","messageId":"a8874cde-cd00-41b0-ba41-ab2fd52ce45d@inria.fr","threadId":"64143","inReplyTo":"F7295141-49F5-4013-911A-7730C130F8CC@gmail.com","subject":"Re: [PATCH 0/3] extend --ignore-other-worktrees to 'rebase', add hints","fromName":"Gabriel Scherer","fromEmail":"gabriel.scherer@inria.fr","sentAt":"2025-09-13T20:02:32Z","receivedAt":"2025-09-13T20:02:35Z","isPatch":true,"sender":{"key":"gabriel.scherer@inria.fr","avatar":null},"body":"Thanks for looking!\n\nOn 13/09/2025 21:30, Ben Knoble wrote:\n> I’m eager to see further reviews, but nothing I saw in this series stuck out as a major problem. I saw we updated the rebase test cases; should we add some more for checkout or worktree?\n\nThere is already a check of the --ignore-other-worktrees option for \n'checkout' in t/t2060-switch.sh. The test only records success or \nfailure, not hints; but I checked manually that the hints are shown as \nexpected.\n\nThere are code paths in 'worktree add' that call the same \ndie_if_checked_out function, but I did not touch those. They seem to \nsupport the --force option to disable the check, and we could also have \na hint to make this self-discoverable. (One could suggest also having a \n--ignore-other-worktrees option in 'worktree' for consistency, but \nunlike 'checkout' the --force option currently has no additional effect \nthan ignoring other worktrees.) Please let me know if you think that \nsome changes to worktree.c should be included in the present patchset \nfor consistency.\n\n"},{"id":"526262","messageId":"be510685-3be1-4f71-806a-6b580bb1cf21@app.fastmail.com","threadId":"64143","inReplyTo":"20250913141327.2775228-2-gabriel.scherer@inria.fr","subject":"Re: [PATCH 1/3] checkout: provide hint when failing due to another worktree","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2025-09-13T20:55:01Z","receivedAt":"2025-09-13T20:56:16Z","isPatch":true,"sender":{"key":"kristofferhaugsbakk@fastmail.com","avatar":null},"body":"Unrelated: I found it confusing that my `co = checkout` alias did not\nwork with this fresh-off-the-press Advice:[1]\n\n```\n$ ./git co master\nfatal: 'master' is already used by worktree at '<path>'\n$ ./git checkout master\nfatal: 'master' is already used by worktree at '<patch>'\nhint: Use --detach to avoid this restriction,\nhint: or --ignore-other-worktrees to ignore it.\nhint: Disable this message with \"git config set advice.branchUsedInOtherWorktree false\"\n```\n\nBut it did for this older Advice (which is in my installed git(1)):\n\n```\n$ ./git co -b .. @\nfatal: '..' is not a valid branch name\nhint: See `man git check-ref-format`\nhint: Disable this message with \"git config set advice.refSyntax false\"\n```\n\nIt’s because aliases are run as a subprocess from the `git` in `PATH`:\n\n```\nstrvec_push(&cmd.args, \"git\");\n```\n\n[1]: Chain of events:\n\n1. Try to trigger the Advice in this series\n2. ... but it doesn’t\n3. Is the code wrong?\n4. Wait, I’m using my alias (which I always use; I don’t think about it)\n5. I test with `git checkout`: it works\n6. ... so aliases don’t work with Advice?\n7. Test an existing Advice that I know about\n8. ... but it does work with aliases\n9.–15. ...\n\nIt was part of the process.  I didn’t *decide* to get hung up on it. ;)\n\nOn Sat, Sep 13, 2025, at 16:13, Gabriel Scherer wrote:\n> From: \"Gabriel.Scherer\" <gabriel.scherer@inria.fr>\n>\n> When checkout/switch fails because the target branch is already used\n> by another worktree, we now hint that the user could use --detach or\n> --ignore-other-worktrees.\n\nThe commit message is supposed to discuss what the code does without the\npatch in the present tense.  What the patch does is in the imperative\nmood.  Refer to `Documentation/SubmittingPatches`, “imperative mood”.\n\nMaybe there should be a paragraph which motivates the need for an Advice\nand these two in particular?  You could also concievably advise removing\nthe worktree. :)\n\n> Note: this error can also happen on rebase, which unfortunately does\n> not support --ignore-other-worktrees. We do not show advice in this\n> case, and leave 'rebase --ignore-other-worktrees' to future work.\n\nAfter reading this I thought this was not handled by this patch series.\nBut you add the this option to git-rebase(1) in the second patch.\n\n“Future work” suggests to me something ranging from:\n\n• there is another patch series that deal with this; or\n• there are no plans to do this (but it could be done in theory).\n\n>\n> Signed-off-by: Gabriel Scherer <gabriel.scherer@inria.fr>\n> ---\n>  Documentation/config/advice.adoc |  3 +++\n>  advice.c                         |  1 +\n>  advice.h                         |  1 +\n>  branch.c                         | 13 +++++++++++--\n>  branch.h                         |  4 ++++\n>  builtin/checkout.c               | 12 ++++++++++--\n>  6 files changed, 30 insertions(+), 4 deletions(-)\n>\n> diff --git a/Documentation/config/advice.adoc\n> b/Documentation/config/advice.adoc\n> index 257db58918..9ee64f44ea 100644\n> --- a/Documentation/config/advice.adoc\n> +++ b/Documentation/config/advice.adoc\n> @@ -27,6 +27,9 @@ all advice messages.\n>  \t\tShown when a fetch refspec for multiple remotes maps to\n>  \t\tthe same remote-tracking branch namespace and causes branch\n>  \t\ttracking set-up to fail.\n> +\tbranchUsedInOtherWorktree::\n> +\t\tShown when the user attemps to switch to a branch\n> +\t\tthat is already checked out in another worktree.\n\nThis maintains sort-order which is good.  It is also consistent in all\npoints with 95c987e6fad (advice: make all entries stylistically\nconsistent, 2024-03-05) for what it’s worth.\n\nI also think the wording/formulation is great.\n\n>  \tcheckoutAmbiguousRemoteBranchName::\n>  \t\tShown when the argument to\n>  \t\tlinkgit:git-checkout[1] and linkgit:git-switch[1]\n> diff --git a/advice.c b/advice.c\n> index e5f0ff8449..5c9b763472 100644\n> --- a/advice.c\n> +++ b/advice.c\n> @@ -50,6 +50,7 @@ static struct {\n>  \t[ADVICE_AMBIGUOUS_FETCH_REFSPEC]\t\t= { \"ambiguousFetchRefspec\" },\n>  \t[ADVICE_AM_WORK_DIR] \t\t\t\t= { \"amWorkDir\" },\n>  \t[ADVICE_CHECKOUT_AMBIGUOUS_REMOTE_BRANCH_NAME] \t= { \"checkoutAmbiguousRemoteBranchName\" },\n> +\t[ADVICE_BRANCH_USED_IN_OTHER_WORKTREE]\t\t= { \"branchUsedInOtherWorktree\" },\n\nThis too looks like it should be in sort order.  If so you are inserting\nat the wrong place.\n\n>  \t[ADVICE_COMMIT_BEFORE_MERGE]\t\t\t= { \"commitBeforeMerge\" },\n>  \t[ADVICE_DEFAULT_BRANCH_NAME]\t\t\t= { \"defaultBranchName\" },\n>  \t[ADVICE_DETACHED_HEAD]\t\t\t\t= { \"detachedHead\" },\n> diff --git a/advice.h b/advice.h\n> index 727dcecf4a..6b11df945b 100644\n> --- a/advice.h\n> +++ b/advice.h\n> @@ -16,6 +16,7 @@ enum advice_type {\n>  \tADVICE_ADD_IGNORED_FILE,\n>  \tADVICE_AMBIGUOUS_FETCH_REFSPEC,\n>  \tADVICE_AM_WORK_DIR,\n> +\tADVICE_BRANCH_USED_IN_OTHER_WORKTREE,\n\nCorrect sort order (if there is one).\n\n>  \tADVICE_CHECKOUT_AMBIGUOUS_REMOTE_BRANCH_NAME,\n>  \tADVICE_COMMIT_BEFORE_MERGE,\n>  \tADVICE_DEFAULT_BRANCH_NAME,\n> diff --git a/branch.c b/branch.c\n> index 26be358347..76aa2cbf44 100644\n> --- a/branch.c\n> +++ b/branch.c\n> @@ -844,7 +844,7 @@ void remove_branch_state(struct repository *r, int\n> verbose)\n>  \tremove_merge_branch_state(r);\n>  }\n>[snip diff]\n> diff --git a/builtin/checkout.c b/builtin/checkout.c\n> index f9453473fe..e4b78f4a05 100644\n> --- a/builtin/checkout.c\n> +++ b/builtin/checkout.c\n> @@ -1582,8 +1582,16 @@ static void\n> die_if_switching_to_a_branch_in_use(struct checkout_opts *opts,\n>  \t\treturn;\n>  \thead_ref = refs_resolve_refdup(get_main_ref_store(the_repository),\n>  \t\t\t\t       \"HEAD\", 0, NULL, &flags);\n> -\tif (head_ref && (!(flags & REF_ISSYMREF) || strcmp(head_ref,\n> full_ref)))\n> -\t\tdie_if_checked_out(full_ref, 1);\n> +\tif (head_ref && (!(flags & REF_ISSYMREF) || strcmp(head_ref,\n> full_ref))) {\n> +\t\tint code = die_message_if_checked_out(full_ref, 1);\n> +\t\tif (code) {\n> +\t\t\tadvise_if_enabled(\n> +\t\t\t\tADVICE_BRANCH_USED_IN_OTHER_WORKTREE,\n> +\t\t\t\t_(\"Use --detach to avoid this restriction,\\n\"\n> +\t\t\t\t\"or --ignore-other-worktrees to ignore it.\"));\n\nI don’t know if `--detach` will “avoid” the restriction.  (In fact\n`--ignore-other-worktrees` might be the one that *avoids* it (turns it\noff)?)\n\nTechnically the only point of being-on-a-branch is to be able to advance\nit.  You know that.  But does the advice-receiver?  Because they might\nuse the hint to get what they want immediately.  Then later wonder why\nall the work they did on the branch “had no effect”.\n\n> +\t\t\texit(code);\n> +\t\t}\n> +\t}\n>  \tfree(head_ref);\n>  }\n>\n> --\n> 2.51.0\n\nNo updates to tests were covered in another email.\n\n-- \nKristoffer Haugsbakk\n"},{"id":"526269","messageId":"d44109a1-0ff5-49f8-885b-9aae195ec492@inria.fr","threadId":"64143","inReplyTo":"be510685-3be1-4f71-806a-6b580bb1cf21@app.fastmail.com","subject":"Re: [PATCH 1/3] checkout: provide hint when failing due to another worktree","fromName":"Gabriel Scherer","fromEmail":"gabriel.scherer@inria.fr","sentAt":"2025-09-14T07:50:57Z","receivedAt":"2025-09-14T07:50:58Z","isPatch":true,"sender":{"key":"gabriel.scherer@inria.fr","avatar":null},"body":"Thanks for your feedback -- I fixed the sort order, and will try to \nreword the commit description as suggested.\n\nOn 13/09/2025 22:55, Kristoffer Haugsbakk wrote:\n>> +\t\t\tadvise_if_enabled(\n>> +\t\t\t\tADVICE_BRANCH_USED_IN_OTHER_WORKTREE,\n>> +\t\t\t\t_(\"Use --detach to avoid this restriction,\\n\"\n>> +\t\t\t\t\"or --ignore-other-worktrees to ignore it.\"));\n> \n> I don’t know if `--detach` will “avoid” the restriction.  (In fact\n> `--ignore-other-worktrees` might be the one that *avoids* it (turns it\n> off)?)\n> \n> Technically the only point of being-on-a-branch is to be able to advance\n> it.  You know that.  But does the advice-receiver?  Because they might\n> use the hint to get what they want immediately.  Then later wonder why\n> all the work they did on the branch “had no effect”.\n\nIn my in-progress version of the patch, the reworded advice is as follows:\n\nfatal: 'foo' is already used by worktree at '/home/gasche/Prog/foo'\nhint: If you want to proceed anyway, try again with \n--ignore-other-worktrees.\nhint: Changes to the branch will also impact the other worktrees.\nhint:\nhint: If you want to detach HEAD at that branch, try again with the \n--detach option.\n\n(The last part is shown when ADVICE_SUGGEST_DETACHING_HEAD is enabled,\nand reuses the existing wording for that advice.)\n\n"},{"id":"526281","messageId":"6B2DF1C9-8745-4733-8082-9C37BEF12150@gmail.com","threadId":"64143","inReplyTo":"be510685-3be1-4f71-806a-6b580bb1cf21@app.fastmail.com","subject":"Re: [PATCH 1/3] checkout: provide hint when failing due to another worktree","fromName":"Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2025-09-14T19:03:32Z","receivedAt":"2025-09-14T19:03:45Z","isPatch":true,"sender":{"key":"ben.knoble@gmail.com","avatar":"https://avatars.githubusercontent.com/u/22802209?v=4"},"body":"\n> Le 13 sept. 2025 à 16:56, Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com> a écrit :\n> \n> Unrelated: I found it confusing that my `co = checkout` alias did not\n> work with this fresh-off-the-press Advice:[1]\n> \n> ```\n> $ ./git co master\n> fatal: 'master' is already used by worktree at '<path>'\n> $ ./git checkout master\n> fatal: 'master' is already used by worktree at '<patch>'\n> hint: Use --detach to avoid this restriction,\n> hint: or --ignore-other-worktrees to ignore it.\n> hint: Disable this message with \"git config set advice.branchUsedInOtherWorktree false\"\n> ```\n> \n> But it did for this older Advice (which is in my installed git(1)):\n> \n> ```\n> $ ./git co -b .. @\n> fatal: '..' is not a valid branch name\n> hint: See `man git check-ref-format`\n> hint: Disable this message with \"git config set advice.refSyntax false\"\n> ```\n> \n> It’s because aliases are run as a subprocess from the `git` in `PATH`:\n> \n> ```\n> strvec_push(&cmd.args, \"git\");\n> ```\n> \n> [1]: Chain of events:\n> \n> 1. Try to trigger the Advice in this series\n> 2. ... but it doesn’t\n> 3. Is the code wrong?\n> 4. Wait, I’m using my alias (which I always use; I don’t think about it)\n> 5. I test with `git checkout`: it works\n> 6. ... so aliases don’t work with Advice?\n> 7. Test an existing Advice that I know about\n> 8. ... but it does work with aliases\n> 9.–15. ...\n> \n> It was part of the process.  I didn’t *decide* to get hung up on it. ;)\n\nUsing bin-wrappers/git should set things up correctly, I think?"},{"id":"526282","messageId":"1A8DE1F7-6C83-4ACA-A9D4-D686787EA9BE@gmail.com","threadId":"64143","inReplyTo":"6B2DF1C9-8745-4733-8082-9C37BEF12150@gmail.com","subject":"Re: [PATCH 1/3] checkout: provide hint when failing due to another worktree","fromName":"Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2025-09-14T19:06:15Z","receivedAt":"2025-09-14T19:06:28Z","isPatch":true,"sender":{"key":"ben.knoble@gmail.com","avatar":"https://avatars.githubusercontent.com/u/22802209?v=4"},"body":"\n> Le 14 sept. 2025 à 15:03, Ben Knoble <ben.knoble@gmail.com> a écrit :\n> \n> \n>> Le 13 sept. 2025 à 16:56, Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com> a écrit :\n>> \n>> Unrelated: I found it confusing that my `co = checkout` alias did not\n>> work with this fresh-off-the-press Advice:[1]\n>> \n>> ```\n>> $ ./git co master\n>> fatal: 'master' is already used by worktree at '<path>'\n>> $ ./git checkout master\n>> fatal: 'master' is already used by worktree at '<patch>'\n>> hint: Use --detach to avoid this restriction,\n>> hint: or --ignore-other-worktrees to ignore it.\n>> hint: Disable this message with \"git config set advice.branchUsedInOtherWorktree false\"\n>> ```\n>> \n>> But it did for this older Advice (which is in my installed git(1)):\n>> \n>> ```\n>> $ ./git co -b .. @\n>> fatal: '..' is not a valid branch name\n>> hint: See `man git check-ref-format`\n>> hint: Disable this message with \"git config set advice.refSyntax false\"\n>> ```\n>> \n>> It’s because aliases are run as a subprocess from the `git` in `PATH`:\n>> \n>> ```\n>> strvec_push(&cmd.args, \"git\");\n>> ```\n>> \n>> [1]: Chain of events:\n>> \n>> 1. Try to trigger the Advice in this series\n>> 2. ... but it doesn’t\n>> 3. Is the code wrong?\n>> 4. Wait, I’m using my alias (which I always use; I don’t think about it)\n>> 5. I test with `git checkout`: it works\n>> 6. ... so aliases don’t work with Advice?\n>> 7. Test an existing Advice that I know about\n>> 8. ... but it does work with aliases\n>> 9.–15. ...\n>> \n>> It was part of the process.  I didn’t *decide* to get hung up on it. ;)\n> \n> Using bin-wrappers/git should set things up correctly, I think?\n\nOk, just saw the other patch series and see how this could not work. Thanks. "},{"id":"526283","messageId":"26e828ef-b1df-4618-95dc-f6f58fb8c369@app.fastmail.com","threadId":"64143","inReplyTo":"6B2DF1C9-8745-4733-8082-9C37BEF12150@gmail.com","subject":"Re: [PATCH 1/3] checkout: provide hint when failing due to another worktree","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2025-09-14T19:32:32Z","receivedAt":"2025-09-14T19:33:35Z","isPatch":true,"sender":{"key":"kristofferhaugsbakk@fastmail.com","avatar":null},"body":"On Sun, Sep 14, 2025, at 21:03, Ben Knoble wrote:\n>>[snip]\n>> It was part of the process.  I didn’t *decide* to get hung up on it. ;)\n>\n> Using bin-wrappers/git should set things up correctly, I think?\n\nThat does work for me.  Thanks.\n"},{"id":"526308","messageId":"xmqqikhkhzbm.fsf@gitster.g","threadId":"64143","inReplyTo":"d44109a1-0ff5-49f8-885b-9aae195ec492@inria.fr","subject":"Re: [PATCH 1/3] checkout: provide hint when failing due to another worktree","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-09-15T08:53:01Z","receivedAt":"2025-09-15T08:53:04Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Gabriel Scherer <gabriel.scherer@inria.fr> writes:\n\n> In my in-progress version of the patch, the reworded advice is as follows:\n>\n> fatal: 'foo' is already used by worktree at '/home/gasche/Prog/foo'\n> hint: If you want to proceed anyway, try again with\n> --ignore-other-worktrees.\n> hint: Changes to the branch will also impact the other worktrees.\n> hint:\n> hint: If you want to detach HEAD at that branch, try again with the\n> --detach option.\n\nTo those who _need_ these hint messages (in other words, those who\ncannot choose the right way to do what they wanted to do without\ngetting hints), I suspect think \"if you want to proceed anyway\",\n\"impact\" and \"if you want to\" are not concrete enough to help them\nmake the right choices.\n\n\"If you want to proceed anyway\"---of course they all do, because\nthey do not know what risks they are taking, and this message does\nnot tell them about.  So that isn't very helpful message.\n\nChanges to the branch would not change the index or any files in the\nworking tree of other worktree, leading these users to think that\nthey safely live in two separte isolated worlds in these two\nseparate worktrees.  Is it clear to them that the \"impact\" you are\ntalking about is exactly the fact that these changes are *NOT*\npropagated to other worktree?\n\nThen you have \"if you want to\" without telling the readers why they\nshould \"want to\" (or not) detach.  Which is not all that helpful.\nWhy should I go into the scary sounding \"detached HEAD\" mode?  For\nwhat for?  If a user can answer that question themselves, they do\nnot even need that hint.\n\nI think the message should help the readers eventually realize the\nfollowing things to make intelligent decisions.  Making them short\nto fit in the \"hint:\" messages is left as an exercise ;-)\n\n - 'foo' is already in use and in which worktree.  Your message\n   \"fatal:\" is very clear and is good.\n\n - if you checkout 'foo' here and start growing or otherwise\n   updating the history of 'foo' in this worktree, the index and the\n   working tree files of other worktree(s) will go out of sync with\n   the tip of 'foo'.  if they 'git commit' from that state, for\n   example, it is very likely that they will record a change that\n   reverts your changes from the history of 'foo', and you do not\n   want that.\n\n - if you want to grow history of 'foo' in potentially different\n   direction from what the other worktree with 'foo' is working on,\n   you are better off creating a separte branch 'foo2', with\n   anticipation that you'll eventually merge them together.\n\n - if you only want to browse the files or build but have no\n   intention to change the files or make commits, then you can have\n   the HEAD of this working tree detached at the commit at the tip\n   of 'foo'.  An advantage of this approach is that it will keep you\n   honest, if you know that you are *not* on 'foo', but not on any\n   branch, it would discourage you from making commits and\n   disturbing the other working tree.  Another advantage is that\n   when you do need to make commits (perhaps while you are browsing\n   the files, you may find small typos you want to fix), you can at\n   that time run \"git checkout -b foo-typofix\" to create a new\n   branch and commit, without disturbing the other worktree that\n   have 'foo' checked out.\n\n"},{"id":"526334","messageId":"c7f9da8f-61ae-4ebe-b09e-a0c72f84a334@gmail.com","threadId":"64143","inReplyTo":"20250913141327.2775228-1-gabriel.scherer@inria.fr","subject":"Re: [PATCH 0/3] extend --ignore-other-worktrees to 'rebase', add hints","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2025-09-15T10:09:41Z","receivedAt":"2025-09-15T10:09:45Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Gabriel\n\nOn 13/09/2025 15:13, Gabriel Scherer wrote:\n> The old 'workdir' contribution script was removed from git upstream in May\n> 2025, as it is largely superseded by the 'worktree' command.\n> \n> One significant difference between the old script and the command is that\n> 'git' refuses to checkout or rebase branches that are already checked out in\n> another worktree. My understanding of the reasoning is that users may be\n> surprised when a clean worktree becomes dirty as its index is changed from\n> another worktree. However, this safety net adds a mental burden to worktree\n> users, as they have to keep the other worktrees in mind when moving\n> branches. Old goats like me who are used to the old 'workdir' script find\n> this restriction somewhat painful.\n> \n> See the discussion thread\n>    https://lore.kernel.org/git/5580aa89-09f1-426e-8483-c99481c998ab@gmail.com/\n> about this transition.\n> \n> The present patch series tries to provide a smoother migration path for\n> supporters of worktree independence:\n> \n>   - when 'checkout' refuses because the branch is used in another worktree,\n>     display a 'hint' that mentions the possibility of using '--detach'\n>     instead, and the '--ignore-other-worktrees' option to proceed anyway.\n\nI think this is a good idea, though I agree with Junio that we want the \nhint to be a bit more explicit about where using --detach or \n--ignore-other-worktrees are appropriate.\n>   - add support for '--ignore-other-worktrees' in 'rebase' as well, with\n>     a similar hint.\n\nI'm less convinced this is a good idea as the rebase command updates the \nbranch which is going to be confusing if the branch is checked out \nelsewhere.\n\nThanks\n\nPhillip\n> In the future I would be interested in adding an option\n> 'branch.ignoreOtherWorktrees' to be able to ignore other worktrees globally.\n> \n> Note: this is my first experience submitting a patch to the Git project, so\n> I apologize in advance for any mishap and welcome beginner-level feedback.\n> \n> Cc: Junio C Hamano <gitster@pobox.com>\n> Cc: D. Ben Knoble <ben.knoble@gmail.com>\n> Cc: Phillip Wood <phillip.wood@dunelm.org.uk>\n> \n> Signed-off-by: Gabriel Scherer <gabriel.scherer@inria.fr>\n> \n> Gabriel.Scherer (3):\n>    checkout: provide hint when failing due to another worktree\n>    rebase: support --ignore-other-worktrees\n>    rebase: hint when failing on branch used by another worktree\n> \n>   Documentation/config/advice.adoc |  3 +++\n>   Documentation/git-rebase.adoc    |  6 ++++++\n>   advice.c                         |  1 +\n>   advice.h                         |  1 +\n>   branch.c                         | 13 +++++++++++--\n>   branch.h                         |  4 ++++\n>   builtin/checkout.c               | 12 ++++++++++--\n>   builtin/rebase.c                 | 19 ++++++++++++++++++-\n>   t/t3400-rebase.sh                |  4 +++-\n>   9 files changed, 57 insertions(+), 6 deletions(-)\n> \n\n"},{"id":"526335","messageId":"779ec8b7-9939-4860-bdc2-6d620ecfad24@gmail.com","threadId":"64143","inReplyTo":"20250913141327.2775228-3-gabriel.scherer@inria.fr","subject":"Re: [PATCH 2/3] rebase: support --ignore-other-worktrees","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2025-09-15T10:09:48Z","receivedAt":"2025-09-15T10:09:52Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Gabriel\n\nOn 13/09/2025 15:13, Gabriel Scherer wrote:\n> From: \"Gabriel.Scherer\" <gabriel.scherer@inria.fr>\n> \n> rebase can currently fail if the branch to rebase is checked out in\n> another worktree, and there is no way for users to override this\n> error. We add support for the '--ignore-other-worktrees' option of\n> 'checkout'.\n\nI'm not sure we want to be encouraging users to rebase a branch that is \nalready checked out in another worktree. Unlike the checkout case where \nthey maybe just reading the code and not updating the branch, rebase \nwill update the branch which is going to be confusing. We could, \nperhaps, add a hint suggesting that if they are making experimental \nchanges, they might want to rebase a detached HEAD instead with\n\n     git rebase <upstream> <branch>^0\n\nbut I'm not sure if that is helpful or if using a detached HEAD will \njust confuse users.\n\nThanks\n\nPhillip\n\n> Signed-off-by: Gabriel Scherer <gabriel.scherer@inria.fr>\n> ---\n>   Documentation/git-rebase.adoc |  6 ++++++\n>   builtin/rebase.c              | 11 ++++++++++-\n>   t/t3400-rebase.sh             |  4 +++-\n>   3 files changed, 19 insertions(+), 2 deletions(-)\n> \n> diff --git a/Documentation/git-rebase.adoc b/Documentation/git-rebase.adoc\n> index 005caf6164..b703d4056e 100644\n> --- a/Documentation/git-rebase.adoc\n> +++ b/Documentation/git-rebase.adoc\n> @@ -305,6 +305,12 @@ see the `--empty` flag.\n>   +\n>   See also INCOMPATIBLE OPTIONS below.\n>   \n> +--ignore-other-worktrees::\n> +\tBy default, `git rebase` refuses when the branch to rebase is\n> +\talready checked out or otherwise in use by another\n> +\tworktree. With this option, other worktrees are ignored and\n> +\tthe rebase proceeds anyway.\n> +\n>   --reapply-cherry-picks::\n>   --no-reapply-cherry-picks::\n>   \tReapply all clean cherry-picks of any upstream commit instead\n> diff --git a/builtin/rebase.c b/builtin/rebase.c\n> index 3c85768d29..7a57ebd852 100644\n> --- a/builtin/rebase.c\n> +++ b/builtin/rebase.c\n> @@ -128,6 +128,7 @@ struct rebase_options {\n>   \tstruct strbuf git_format_patch_opt;\n>   \tint reschedule_failed_exec;\n>   \tint reapply_cherry_picks;\n> +\tint ignore_other_worktrees;\n>   \tint fork_point;\n>   \tint update_refs;\n>   \tint config_autosquash;\n> @@ -146,6 +147,7 @@ struct rebase_options {\n>   \t\t.git_format_patch_opt = STRBUF_INIT,\t\\\n>   \t\t.fork_point = -1,\t\t\t\\\n>   \t\t.reapply_cherry_picks = -1,             \\\n> +\t\t.ignore_other_worktrees = -1,           \\\n>   \t\t.allow_empty_message = 1,               \\\n>   \t\t.autosquash = -1,                       \\\n>   \t\t.rebase_merges = -1,                    \\\n> @@ -1234,6 +1236,8 @@ int cmd_rebase(int argc,\n>   \t\t\t N_(\"automatically re-schedule any `exec` that fails\")),\n>   \t\tOPT_BOOL(0, \"reapply-cherry-picks\", &options.reapply_cherry_picks,\n>   \t\t\t N_(\"apply all changes, even those already present upstream\")),\n> +\t\tOPT_BOOL(0, \"ignore-other-worktrees\", &options.ignore_other_worktrees,\n> +\t\t\t N_(\"do not check if another worktree is using the branch to rebase\")),\n>   \t\tOPT_END(),\n>   \t};\n>   \tint i;\n> @@ -1580,6 +1584,10 @@ int cmd_rebase(int argc,\n>   \t\t\t(options.flags & REBASE_INTERACTIVE_EXPLICIT);\n>   \t}\n>   \n> +\tif (options.ignore_other_worktrees == -1) {\n> +\t\toptions.ignore_other_worktrees = 0;\n> +\t}\n> +\n>   \tif (options.type == REBASE_UNSPECIFIED) {\n>   \t\tif (!strcmp(options.default_backend, \"merge\"))\n>   \t\t\toptions.type = REBASE_MERGE;\n> @@ -1679,7 +1687,8 @@ int cmd_rebase(int argc,\n>   \t\tstrbuf_reset(&buf);\n>   \t\tstrbuf_addf(&buf, \"refs/heads/%s\", branch_name);\n>   \t\tif (!refs_read_ref(get_main_ref_store(the_repository), buf.buf, &branch_oid)) {\n> -\t\t\tdie_if_checked_out(buf.buf, 1);\n> +\t\t\tif (!options.ignore_other_worktrees)\n> +\t\t\t\tdie_if_checked_out(buf.buf, 1);\n>   \t\t\toptions.head_name = xstrdup(buf.buf);\n>   \t\t\toptions.orig_head =\n>   \t\t\t\tlookup_commit_object(the_repository,\n> diff --git a/t/t3400-rebase.sh b/t/t3400-rebase.sh\n> index c0c00fbb7b..08448b4d4e 100755\n> --- a/t/t3400-rebase.sh\n> +++ b/t/t3400-rebase.sh\n> @@ -407,7 +407,9 @@ test_expect_success 'switch to branch checked out elsewhere fails' '\n>   \t# we test in both worktrees to ensure that works\n>   \t# as expected with \"first\" and \"next\" worktrees\n>   \ttest_must_fail git -C wt1 rebase shared shared &&\n> -\ttest_must_fail git -C wt2 rebase shared shared\n> +\ttest_must_fail git -C wt2 rebase shared shared &&\n> +        # with --ignore-other-worktrees the rebase succeeds\n> +\tgit -C wt1 rebase --ignore-other-worktrees shared shared\n>   '\n>   \n>   test_expect_success 'switch to branch not checked out' '\n\n"},{"id":"526374","messageId":"xmqq8qifit1k.fsf@gitster.g","threadId":"64143","inReplyTo":"779ec8b7-9939-4860-bdc2-6d620ecfad24@gmail.com","subject":"Re: [PATCH 2/3] rebase: support --ignore-other-worktrees","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-09-15T16:23:19Z","receivedAt":"2025-09-15T16:23:22Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Phillip Wood <phillip.wood123@gmail.com> writes:\n\n> Hi Gabriel\n>\n> On 13/09/2025 15:13, Gabriel Scherer wrote:\n>> From: \"Gabriel.Scherer\" <gabriel.scherer@inria.fr>\n>> rebase can currently fail if the branch to rebase is checked out in\n>> another worktree, and there is no way for users to override this\n>> error. We add support for the '--ignore-other-worktrees' option of\n>> 'checkout'.\n>\n> I'm not sure we want to be encouraging users to rebase a branch that\n> is already checked out in another worktree. Unlike the checkout case\n> where they maybe just reading the code and not updating the branch,\n> rebase will update the branch which is going to be confusing. We\n> could, perhaps, add a hint suggesting that if they are making\n> experimental changes, they might want to rebase a detached HEAD\n> instead with\n>\n>     git rebase <upstream> <branch>^0\n>\n> but I'm not sure if that is helpful or if using a detached HEAD will\n> just confuse users.\n\nThe risk of confusion is real in a workflow like this.  Hinting them\nto go to that existing worktree that is used to checkout that branch\nand rebasing it there might be less risky.\n\nBut stepping back a bit, if the user reader wants to rebase the\nbranch in this worktree, instead of in the other worktree, is\nbecause they has uncommitted changes in the worktree that already\nchecks out the branch, the branch may not even be ready to be\nrebased?\n\nThanks.\n"},{"id":"526387","messageId":"0dfe3e31-5486-446e-8af5-20669c06ea64@inria.fr","threadId":"64143","inReplyTo":"xmqqikhkhzbm.fsf@gitster.g","subject":"Re: [PATCH 1/3] checkout: provide hint when failing due to another worktree","fromName":"Gabriel Scherer","fromEmail":"gabriel.scherer@inria.fr","sentAt":"2025-09-15T19:52:19Z","receivedAt":"2025-09-15T19:52:27Z","isPatch":true,"sender":{"key":"gabriel.scherer@inria.fr","avatar":null},"body":"Thanks for the detailed comments!\n\nOn 15/09/2025 10:53, Junio C Hamano wrote:\n> Gabriel Scherer <gabriel.scherer@inria.fr> writes:\n> \n>> In my in-progress version of the patch, the reworded advice is as follows:\n>>\n>> fatal: 'foo' is already used by worktree at '/home/gasche/Prog/foo'\n>> hint: If you want to proceed anyway, try again with\n>> --ignore-other-worktrees.\n>> hint: Changes to the branch will also impact the other worktrees.\n>> hint:\n>> hint: If you want to detach HEAD at that branch, try again with the\n>> --detach option.\n> \n> To those who _need_ these hint messages (in other words, those who\n> cannot choose the right way to do what they wanted to do without\n> getting hints), I suspect think \"if you want to proceed anyway\",\n> \"impact\" and \"if you want to\" are not concrete enough to help them\n> make the right choices.\n> \n> \"If you want to proceed anyway\"---of course they all do, because\n> they do not know what risks they are taking, and this message does\n> not tell them about.  So that isn't very helpful message.\n> \n> Changes to the branch would not change the index or any files in the\n> working tree of other worktree, leading these users to think that\n> they safely live in two separte isolated worlds in these two\n> separate worktrees.  Is it clear to them that the \"impact\" you are\n> talking about is exactly the fact that these changes are *NOT*\n> propagated to other worktree?\n> \n> Then you have \"if you want to\" without telling the readers why they\n> should \"want to\" (or not) detach.  Which is not all that helpful.\n> Why should I go into the scary sounding \"detached HEAD\" mode?  For\n> what for?  If a user can answer that question themselves, they do\n> not even need that hint.\n\nTo my defense, this is the hint wording that is already in the git codebase:\n\n   $ git switch HEAD~3\n   fatal: a branch is expected, got commit 'HEAD~3'\n   hint: If you want to detach HEAD at the commit, try again with the \n--detach option.\n\nI am happy to improve this wording as well if we can converge to \nconcrete recommendations.\n\n> I think the message should help the readers eventually realize the\n> following things to make intelligent decisions.  Making them short\n> to fit in the \"hint:\" messages is left as an exercise ;-)\n\nHints make advanced features self-discoverable -- otherwise we find them \nout by reading the entire doc of a command when we are stuck After \nreading the hint, users can read the documentation in a more targeted \nway to understand the implications.\n\nWould referring the user to the documentation be acceptable?\n\nFor 'detach' hints, there is a detailed section DETACHED HEAD in the \n'checkout' documentation, which the hint could refer to. For example \n(imaginary output):\n\n   $ git checkout HEAD~3fatal: a branch is expected, got commit 'HEAD~3'\n   hint: If you want to detach HEAD at the commit, try again with the \n--detach option.\n   hint: See the \"DETACHED HEAD\" section in the 'git checkout' \ndocumentation.\n\nOn the other hand for --ignore-other-worktrees there is no user-friendly \ndocumentation of these questions currently (I looked at the 'worktree' \ndocumentation, in particular for the --force option, and at the \n--ignore-other-worktrees documentation for 'checkout').\n\nIf you agree in principle, I can update my patchset with a documentation \ncommit that explains the justification for the worktree restriction, \nwhat happens if we ignore this restriction, and what is the recommended \nway to respect it.\n\n>   - 'foo' is already in use and in which worktree.  Your message\n>     \"fatal:\" is very clear and is good.\n> \n>   - if you checkout 'foo' here and start growing or otherwise\n>     updating the history of 'foo' in this worktree, the index and the\n>     working tree files of other worktree(s) will go out of sync with\n>     the tip of 'foo'.  if they 'git commit' from that state, for\n>     example, it is very likely that they will record a change that\n>     reverts your changes from the history of 'foo', and you do not\n>     want that.\n\n(This gets me to wonder if a desirable behavior could be to 'detach' the \nother worktrees that had the same branch checked out, instead of failing \non checkout. Users starting to use the other worktree again would \npossibly notice more quickly that something is amiss.)\n\nFor me this situation is not a big deal: if they commit the removal of \n'foo', presumably they will notice that the diff/changes in their commit \nis not what they expect, and they can come back to the previous state.\n\nI agree that this is surprising and I understand why the project decided \nto discourage this by default ('fatal error' is plenty discouraging), \nbut there is no data loss or anything of the sort, only recoverable \nsurprises.\n\n>   - if you want to grow history of 'foo' in potentially different\n>     direction from what the other worktree with 'foo' is working on,\n>     you are better off creating a separte branch 'foo2', with\n>     anticipation that you'll eventually merge them together.\n\nUse-case examples:\n\n1. my colleague has a long-lived feature branch called 'super-feature'\n2. last year I did a lot of review work on their branch in a separate \nworktree which is still somewhere on my filesystem, but which I am not \nactively working on anymore (and maybe never will)\n3. I am in the middle of a bugfix session in another worktree, and \nsuddenly I want to check if the bug also occurs in 'super-feature'; I \nstash my current stuff, checkout 'super-feature', and run 'git pull' to \nupdate it to match my colleague's remote to get the most recent version \nand test it against this bug.\n\nIn this scenario, I don't want my current work in (3) to be interrupted \nby the fact that an old worktree (2) exists that also tracks \nsuper-feature, and in fact I do want to update my local 'super-feature' \nbranch to the most recent version.\nMaybe later on I will come back to my old super-feature worktree (but \nmaybe in another year), and I will start with a 'git pull' or some other \ncommand, and I will quickly realize that its index is out of date and \nfix it.\n\n>   - if you only want to browse the files or build but have no\n>     intention to change the files or make commits, then you can have\n>     the HEAD of this working tree detached at the commit at the tip\n>     of 'foo'.  An advantage of this approach is that it will keep you\n>     honest, if you know that you are *not* on 'foo', but not on any\n>     branch, it would discourage you from making commits and\n>     disturbing the other working tree.  Another advantage is that\n>     when you do need to make commits (perhaps while you are browsing\n>     the files, you may find small typos you want to fix), you can at\n>     that time run \"git checkout -b foo-typofix\" to create a new\n>     branch and commit, without disturbing the other worktree that\n>     have 'foo' checked out.\n\nI agree that detached-head is a reasonable point in the design space in \nsome cases, so I think that it is reasonable to hint about both options. \nI am happy to put the detach advice first if this has your preference.\n\n(Note: In the earlier mailing-list thread I discarded detached HEAD \nbecause its default rendering in the git bash prompt is unpleasant, it \nshows the commit and does not mention the detached branch name anymore, \nwhich is disorienting. I have since realized that there is a non-default \nsetting GIT_PS1_DESCRIBE_STYLE=branch that can be used to see say \n\"((trunk))\" in that case (when we are detached on top of a \"trunk\" \nbranch, which makes it much more pleasant to use.)\n\n"},{"id":"526417","messageId":"xmqqv7ljarog.fsf@gitster.g","threadId":"64143","inReplyTo":"0dfe3e31-5486-446e-8af5-20669c06ea64@inria.fr","subject":"Re: [PATCH 1/3] checkout: provide hint when failing due to another worktree","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-09-16T05:32:15Z","receivedAt":"2025-09-16T05:32:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Gabriel Scherer <gabriel.scherer@inria.fr> writes:\n\n> On the other hand for --ignore-other-worktrees there is no\n> user-friendly documentation of these questions currently (I looked at\n> the 'worktree' documentation, in particular for the --force option,\n> and at the --ignore-other-worktrees documentation for 'checkout').\n\nOh, that's bad and we should improve them, regardless of what we say\nin the hints.\n\n> restriction, what happens if we ignore this restriction, and what is\n> the recommended way to respect it.\n\nSounds good.\n\n>>   - 'foo' is already in use and in which worktree.  Your message\n>>     \"fatal:\" is very clear and is good.\n>>   - if you checkout 'foo' here and start growing or otherwise\n>>     updating the history of 'foo' in this worktree, the index and the\n>>     working tree files of other worktree(s) will go out of sync with\n>>     the tip of 'foo'.  if they 'git commit' from that state, for\n>>     example, it is very likely that they will record a change that\n>>     reverts your changes from the history of 'foo', and you do not\n>>     want that.\n>\n> (This gets me to wonder if a desirable behavior could be to 'detach'\n> the other worktrees that had the same branch checked out, instead of\n> failing on checkout. Users starting to use the other worktree again\n> would possibly notice more quickly that something is amiss.)\n\nI generally advise against pulling the rug under somebody else's\nfeet.  You do not know what that other worktree is used for, or if\nsomebody is using it right now making changes and whatnot.  What\nhappens in the worktree that the end-user has just issued the\ncommand you are executing is much more controllable.\n\n> For me this situation is not a big deal: if they commit the removal of\n> 'foo', presumably they will notice that the diff/changes in their\n> commit is not what they expect, and they can come back to the previous\n> state.\n>\n> I agree that this is surprising and I understand why the project\n> decided to discourage this by default ('fatal error' is plenty\n> discouraging), but there is no data loss or anything of the sort, only\n> recoverable surprises.\n\nThe question is how would they, the person who worked on the other\nworking tree that first checked out 'foo' and perhaps worked for\nsome time with local modifications, and then left the worktree so\nlong ago that they forgot that they have a checkout of it (and that\nis why they just got told by \"git checkout\" that there _is_ another\nworktree that checks out 'foo' already exists), _find_ where the\nprevious state is in the first place, once they go back to the other\nworktree.  You may be nice and have advanced the branch by only one\nor two commits, and they may be able to find where they were by\ngoing back a few entries in \"git log\" output.  But you may rebase\nthe branch and the place where they started from in the other\nworktree may no longer exist.  Then what?  It does not sounds like a\nrecoverable surprise to me at all.\n\n>>   - if you want to grow history of 'foo' in potentially different\n>>     direction from what the other worktree with 'foo' is working on,\n>>     you are better off creating a separte branch 'foo2', with\n>>     anticipation that you'll eventually merge them together.\n>\n> Use-case examples:\n>\n> 1. my colleague has a long-lived feature branch called 'super-feature'\n> 2. last year I did a lot of review work on their branch in a separate\n> worktree which is still somewhere on my filesystem, but which I am not\n> actively working on anymore (and maybe never will)\n> 3. I am in the middle of a bugfix session in another worktree, and\n> suddenly I want to check if the bug also occurs in 'super-feature'; I\n> stash my current stuff, checkout 'super-feature', and run 'git pull'\n> to update it to match my colleague's remote to get the most recent\n> version and test it against this bug.\n>\n> In this scenario, I don't want my current work in (3) to be\n> interrupted by the fact that an old worktree (2) exists that also\n> tracks super-feature, and in fact I do want to update my local\n> 'super-feature' branch to the most recent version.\n> Maybe later on I will come back to my old super-feature worktree (but\n> maybe in another year), and I will start with a 'git pull' or some\n> other command, and I will quickly realize that its index is out of\n> date and fix it.\n\nIf #3 involved only \"checkout\" of super-feature to build and test,\nthen detached HEAD is the perfect tool that was designed to be used\nin such a situation.  But if the goal is you want to have _his_ latest\nsuper-feature expanded in your filesystem so that you can build and\ndebug, you do not want to checkout super-feature and pull, which WILL\nmove your super-feature branch and make #1 worktree useless.  They\nmay have made quite a lot of changes, and your previous state, the\nstate you were reviewing (and perhaps you had a few of your own\nfixup patches there) may not even be reachable from their updated\ntip of the super-feature branch.\n\nIf I were in that situation in step #3, I'll probably do\n\n $ git stash save -m 'in the middle of a bugfix session'\n $ git fetch his super-feature\n $ git checkout --detach his/super-feature\n\n"},{"id":"526575","messageId":"xmqqms6tgo33.fsf@gitster.g","threadId":"64143","inReplyTo":"0dfe3e31-5486-446e-8af5-20669c06ea64@inria.fr","subject":"Re: [PATCH 1/3] checkout: provide hint when failing due to another worktree","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-09-17T14:17:52Z","receivedAt":"2025-09-17T14:17:55Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Gabriel Scherer <gabriel.scherer@inria.fr> writes:\n\n> To my defense, this is the hint wording that is already in the git codebase:\n>\n>   $ git switch HEAD~3\n>   fatal: a branch is expected, got commit 'HEAD~3'\n>   hint: If you want to detach HEAD at the commit, try again with the\n>   --detach option.\n>\n> I am happy to improve this wording as well if we can converge to\n> concrete recommendations.\n\nThis looks like a typical apples-and-oranges comparison to me.\n\nI do not see any need to improve the above.  In this case, it is\nclear that the user did want to detach but they just forgot that the\n\"switch\" comand wants an explicit \"--detach\" [*] when switching into\na detached HEAD state.  There is nothing inherently risky in the act\nof detaching HEAD that makes it something to be discouraged.\n\n    Side note: This was deliberately made to behave differently from\n    the \"checkout\" command, which intelligently did the right thing\n    without being told, i.e. HEAD~3 cannot be a branch name, hence\n    it took the command line \"git checkout HEAD~3\" as an obvious\n    request to detach HEAD at that commit.  So if the user came from\n    knowing \"checkout\", it is an easy mistake to make when they\n    switch to \"switch\".  No pun intended.\n\nThis is vastly different from trying to checkout a branch and then\nit turns out that the branch is already in use in somewhere else.\nWe strongly and actively discourage a branch from being used in two\ndifferent places, in order to avoid an update to it from one place\nbreaking the other place.  Unlike detaching HEAD, this one is\nsomething the user needs to think twice before doing so.\n\nAnd in such a request, there is no indication that the user even\nknew that the branch was already in use elsewhere.  It is plausible\nthat the user may not even have tried to check it out if they knew\nit is checked out elsewhere beforehand (if simply because such a\nrequest would be rejected by the safety mechanism); if they only\nwanted to peek, and if they knew there is already a checkout, they\nmay have just cd'ed there to peek, for example.\n\nDepending on what they wanted to do by having a checkout of that\nbranch, a suitable and safe course of action would be different, and\nhints would want to help them make right decisions among various\npossibilities.\n\n>> I think the message should help the readers eventually realize the\n>> following things to make intelligent decisions.  Making them short\n>> to fit in the \"hint:\" messages is left as an exercise ;-)\n>\n> Hints make advanced features self-discoverable -- otherwise we find\n> them out by reading the entire doc of a command when we are stuck\n>\n> After reading the hint, users can read the documentation in a more\n> targeted way to understand the implications.\n\nSure.  I phrased the above paragraph is somewhat awkwardly, but the\npoint I wanted to convey was that the message would never be able to\nteach everything they need to know---rather it should give a good\nstarting point and pointers to lead them in the right directions to\nfind out what the best course of action for their situation.\n\n> Would referring the user to the documentation be acceptable?\n\nSo, yes.  I think risks need to be told in the message to make them\nrealize that blindly proceeding with a hammer without understanding\nconsequence is not a good idea, but we do not need to be exhausive\nin listing what tools other than the hammer are available, and the\nhint message would not have enough room to be a manual.  So a loud\nwarning of risks, and a couple of pointers into the documentation,\nwould be very much appropriate, I would think.\n\nThanks.\n"},{"id":"526592","messageId":"a27a8191-55d7-4b60-ad90-59ab946340bd@inria.fr","threadId":"64143","inReplyTo":"0dfe3e31-5486-446e-8af5-20669c06ea64@inria.fr","subject":"Re: [PATCH 1/3] checkout: provide hint when failing due to another worktree","fromName":"Gabriel Scherer","fromEmail":"gabriel.scherer@inria.fr","sentAt":"2025-09-17T15:25:54Z","receivedAt":"2025-09-17T15:26:02Z","isPatch":true,"sender":{"key":"gabriel.scherer@inria.fr","avatar":null},"body":"Dear git developers,\n\nOn 15/09/2025 21:52, Gabriel Scherer wrote:\n> (This gets me to wonder if a desirable behavior could be to 'detach' the other worktrees that had the same branch checked out, instead of failing on checkout. Users starting to use the other worktree again would possibly notice more quickly that something is amiss.)\n\nAfter the new feedback from Junio, I wonder if I should explore this \nsuggestion more actively.\n\nFor now my goal has been to make --ignore-other-worktrees more \ndiscoverable, for people who are willing to take the risk. (I am \ncomfortable doing this as I have used this workflow for years without \nmuch trouble with the 'workdir' script, but clearly you want to be very \ncareful in how exactly we suggest that it is a possibility.)\n\nWould you prefer a different option to detach the branch at the other \nworktrees? This could be\n   git checkout --detach-other-worktrees <branch>\nfor example.\n\nI did not originally consider this as it requires more expertise in git \ninternal data structures, but it may be easier than finding a way to \nadvertise --ignore-other-worktrees that you are really comfortable with.\n\n"},{"id":"526772","messageId":"19aebe91-a266-430e-a9ac-881cd782f3f4@gmail.com","threadId":"64143","inReplyTo":"a27a8191-55d7-4b60-ad90-59ab946340bd@inria.fr","subject":"Re: [PATCH 1/3] checkout: provide hint when failing due to another worktree","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2025-09-19T14:13:23Z","receivedAt":"2025-09-19T14:13:28Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Gabriel\n\nOn 17/09/2025 16:25, Gabriel Scherer wrote:\n> Dear git developers,\n> \n> On 15/09/2025 21:52, Gabriel Scherer wrote:\n>> (This gets me to wonder if a desirable behavior could be to 'detach' \n>> the other worktrees that had the same branch checked out, instead of \n>> failing on checkout. Users starting to use the other worktree again \n>> would possibly notice more quickly that something is amiss.)\n> \n> After the new feedback from Junio, I wonder if I should explore this \n> suggestion more actively.\n> \n> For now my goal has been to make --ignore-other-worktrees more \n> discoverable, for people who are willing to take the risk. (I am \n> comfortable doing this as I have used this workflow for years without \n> much trouble with the 'workdir' script, but clearly you want to be very \n> careful in how exactly we suggest that it is a possibility.)\n> \n> Would you prefer a different option to detach the branch at the other \n> worktrees? This could be\n>    git checkout --detach-other-worktrees <branch>\n> for example.\n\nIn general we try to avoid having commands run in one worktree affect a \ncheckout in another worktree so I'm not sure we'd really want to go that \nroute.\n\n> I did not originally consider this as it requires more expertise in git \n> internal data structures, but it may be easier than finding a way to \n> advertise --ignore-other-worktrees that you are really comfortable with.\n\nI think it comes down to the same problem that we're not that \ncomfortable with the idea of having the same branch checked out in \nmultiple worktrees. I'd have though having some advice that suggests \nusing --detach should be relatively uncontroversial. Suggesting \n\"--ignore-other-worktrees\" would certainly require some kind of warning. \nIf it is hard to come up with a concise hint maybe we could have an \nexpanded discussion in the documentation and have the hint refer to that?\n\nThanks\n\nPhillip\n"}]}