Re: [PATCH v3 10/11] contrib: remove "git-new-workdir"

From: Phillip Wood <phillip.wood123@gmail.com>
Date: Sep 12, 2025, 20:05 UTC
Message-ID: <4bd78e37-1d96-4d98-b77f-47520200376b@gmail.com>
In-Reply-To: <e6003a2c-bc1b-4cf5-aae7-ef5aa9c82f10@gmail.com>

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

Show 14 quoted lines

> 
> On 08/09/2025 11:58, Kristoffer Haugsbakk wrote:
>> 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

Show 29 quoted lines

> 
>>> 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.
> 
>>> 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]
>