On 08/09/2025 16:22, Gabriel Scherer wrote:

On 08/09/2025 11:58, Kristoffer Haugsbakk wrote:

quoted

On Mon, Sep 8, 2025, at 11:28, Gabriel Scherer wrote:

Thanks. I just tried this, but I think it does not suffice. The --force
option is available to "git worktree add" to create a worktree for a
branch that is already checked out. But typically my workflow is to
create a worktree for a new feature branch, and there from that worktree
temporarily switch to an existing branch using `git checkout`, and there
I get a hard error (if another worktree has this branch) and there is no
--force option to override the worktree limitation at 'checkout' time. I
just tried to test whether worktrees created with --force would allow to
switch to checked-out-in-other-worktrees branches in the future, but
that does not appear to be the case.

If you really want to checkout the same branch in more than one worktree 
you can use "git checkout --ignore-other-worktrees". "git checkout 
--force" predates that option and will, amongst other things, overwrite 
uncommitted changes. Having a separate option avoids nasty surprises 
such as overwriting you uncommitted changes when checking out the same 
branch in more than one worktree.

Thanks

Phillip

quoted

quoted

I understand
why its designers felt that this would provide better guarantees (it
is not a good idea to mutate branch names that are checked out
somewhere else), but checking out various branches to test them and
inspect their code (before returning to the feature branch I am
actively working on) is a common part of my workflow.

I agree, that’s a great use of worktrees.  But I never feel like I have
to checkout the branch itself.  I detach on top of the branch.

I'm afraid `git checkout -d` is not part of my typical git workflow. I
could retrain myself to use it, when I get into a worktree error, but it
is cumbersome to know of this new complexity¹, and various things work
less well in detached state -- for example my bash prompt tells me in
which branch I am, and in detached state it only shows the commit hash.

¹: it would be nice if the fatal-error message on 'git checkout' when
trying to checkout a branch that is active on another worktree would
suggest using `git checkout -d` instead to proceed. I may try to send a
patch to add this information.

quoted

quoted

Getting a 'fatal
error' because some other, independent worktree also checked this
branch out is a hindrance.

Note: I don't know about the `worktree` implementation and whether the
[snip]