public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
From: Phillip Wood <phillip.wood123@gmail•com>
To: Gabriel Scherer <gabriel.scherer@inria•fr>,
	Junio C Hamano <gitster@pobox•com>
Cc: Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail•com>,
	git@vger•kernel.org, "D. Ben Knoble" <ben.knoble@gmail•com>,
	Phillip Wood <phillip.wood@dunelm•org.uk>
Subject: Re: [PATCH 1/3] checkout: provide hint when failing due to another worktree
Date: Fri, 19 Sep 2025 15:13:23 +0100	[thread overview]
Message-ID: <19aebe91-a266-430e-a9ac-881cd782f3f4@gmail.com> (raw)
In-Reply-To: <a27a8191-55d7-4b60-ad90-59ab946340bd@inria.fr>

Hi Gabriel

On 17/09/2025 16:25, Gabriel Scherer wrote:
> Dear git developers,
> 
> On 15/09/2025 21:52, Gabriel Scherer wrote:
>> (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.)
> 
> After the new feedback from Junio, I wonder if I should explore this 
> suggestion more actively.
> 
> For now my goal has been to make --ignore-other-worktrees more 
> discoverable, for people who are willing to take the risk. (I am 
> comfortable doing this as I have used this workflow for years without 
> much trouble with the 'workdir' script, but clearly you want to be very 
> careful in how exactly we suggest that it is a possibility.)
> 
> Would you prefer a different option to detach the branch at the other 
> worktrees? This could be
>    git checkout --detach-other-worktrees <branch>
> for example.

In general we try to avoid having commands run in one worktree affect a 
checkout in another worktree so I'm not sure we'd really want to go that 
route.

> I did not originally consider this as it requires more expertise in git 
> internal data structures, but it may be easier than finding a way to 
> advertise --ignore-other-worktrees that you are really comfortable with.

I think it comes down to the same problem that we're not that 
comfortable with the idea of having the same branch checked out in 
multiple worktrees. I'd have though having some advice that suggests 
using --detach should be relatively uncontroversial. Suggesting 
"--ignore-other-worktrees" would certainly require some kind of warning. 
If it is hard to come up with a concise hint maybe we could have an 
expanded discussion in the documentation and have the hint refer to that?

Thanks

Phillip

  reply	other threads:[~2025-09-19 14:13 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-13 14:13 [PATCH 0/3] extend --ignore-other-worktrees to 'rebase', add hints Gabriel Scherer
2025-09-13 14:13 ` [PATCH 1/3] checkout: provide hint when failing due to another worktree Gabriel Scherer
2025-09-13 20:55   ` Kristoffer Haugsbakk
2025-09-14  7:50     ` Gabriel Scherer
2025-09-15  8:53       ` Junio C Hamano
2025-09-15 19:52         ` Gabriel Scherer
2025-09-16  5:32           ` Junio C Hamano
2025-09-17 14:17           ` Junio C Hamano
2025-09-17 15:25           ` Gabriel Scherer
2025-09-19 14:13             ` Phillip Wood [this message]
2025-09-14 19:03     ` Ben Knoble
2025-09-14 19:06       ` Ben Knoble
2025-09-14 19:32       ` Kristoffer Haugsbakk
2025-09-13 14:13 ` [PATCH 2/3] rebase: support --ignore-other-worktrees Gabriel Scherer
2025-09-15 10:09   ` Phillip Wood
2025-09-15 16:23     ` Junio C Hamano
2025-09-13 14:13 ` [PATCH 3/3] rebase: hint when failing on branch used by another worktree Gabriel Scherer
2025-09-13 19:30 ` [PATCH 0/3] extend --ignore-other-worktrees to 'rebase', add hints Ben Knoble
2025-09-13 20:02   ` Gabriel Scherer
2025-09-15 10:09 ` Phillip Wood

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=19aebe91-a266-430e-a9ac-881cd782f3f4@gmail.com \
    --to=phillip.wood123@gmail$(echo .)com \
    --cc=ben.knoble@gmail$(echo .)com \
    --cc=gabriel.scherer@inria$(echo .)fr \
    --cc=git@vger$(echo .)kernel.org \
    --cc=gitster@pobox$(echo .)com \
    --cc=kristofferhaugsbakk@fastmail$(echo .)com \
    --cc=phillip.wood@dunelm$(echo .)org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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