Re: [PATCH 2/3] rebase: support --ignore-other-worktrees

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 15, 2025, 16:23 UTC
Message-ID: <xmqq8qifit1k.fsf@gitster.g>
In-Reply-To: <779ec8b7-9939-4860-bdc2-6d620ecfad24@gmail.com>

Phillip Wood <phillip.wood123@gmail.com> writes:

Show 21 quoted lines

> Hi Gabriel
>
> On 13/09/2025 15:13, Gabriel Scherer wrote:
>> From: "Gabriel.Scherer" <gabriel.scherer@inria.fr>
>> rebase can currently fail if the branch to rebase is checked out in
>> another worktree, and there is no way for users to override this
>> error. We add support for the '--ignore-other-worktrees' option of
>> 'checkout'.
>
> I'm not sure we want to be encouraging users to rebase a branch that
> is already checked out in another worktree. Unlike the checkout case
> where they maybe just reading the code and not updating the branch,
> rebase will update the branch which is going to be confusing. We
> could, perhaps, add a hint suggesting that if they are making
> experimental changes, they might want to rebase a detached HEAD
> instead with
>
>     git rebase <upstream> <branch>^0
>
> but I'm not sure if that is helpful or if using a detached HEAD will
> just confuse users.

The risk of confusion is real in a workflow like this. Hinting them to go to that existing worktree that is used to checkout that branch and rebasing it there might be less risky.

But stepping back a bit, if the user reader wants to rebase the branch in this worktree, instead of in the other worktree, is because they has uncommitted changes in the worktree that already checks out the branch, the branch may not even be ready to be rebased?

Thanks.