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

From: Junio C Hamano <[email-masked]>
Date: Mon, 15 Sep 2025 09:23:19 -0700

Phillip Wood <[email-masked]> writes:

> Hi Gabriel
>
> On 13/09/2025 15:13, Gabriel Scherer wrote:
>> From: "Gabriel.Scherer" <[email-masked]>
>> 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.