Able to checkout same branch in multiple worktrees when using symbolic-refs

Able to checkout same branch in multiple worktrees when using symbolic-refs

[Austin Morton]

Hello,

When using a symbolic-ref I am able to inadvertently checkout the same
branch in multiple worktrees when using the symbolic-ref name, despite
being prevented from doing so if I use the target branch name.

Below is a minimal reproducer:

$ git --version
git version 2.36.0
$ git init .
$ git status
$ git commit --allow-empty -m "Initial commit"
$ git symbolic-ref refs/heads/main refs/heads/master
$ git worktree add ../worktree2
$ git worktree list
/home/amorton/test/worktree1 cd8312d [master]
/home/amorton/test/worktree2 cd8312d [worktree2]
$ cd ../worktree2
$ git checkout master
fatal: 'master' is already checked out at '/home/amorton/test/worktree1'
$ git checkout main
Switched to branch 'main'
$ git worktree list
/home/amorton/test/worktree1 cd8312d [master]
/home/amorton/test/worktree2 cd8312d [master]


-- 
Austin Morton
austin.morton@aquatic.com

Re: Able to checkout same branch in multiple worktrees when using symbolic-refs

[Junio C Hamano]

Austin Morton <austin.morton@aquatic.com> writes:

> When using a symbolic-ref I am able to inadvertently checkout the same
> branch in multiple worktrees when using the symbolic-ref name, despite
> being prevented from doing so if I use the target branch name.

Don't do that if it hurts ;-)

If you checked out 'main' in the secondary worktree and made a
commit there, the symbolic-ref makes 'master' to be updated,
confusing the primary worktree whose index and the working tree
files record work relative to the old commit before the secondary
worktree updated it via the symbolic-ref, which is exactly the same
situation that the "do not check out the same branch in two
different worktrees" protection tries to save the user from, but I
do not think we currently do so.

Because this "do not check a branch out twice and let it be futzed
with from the two places" is primarily a mechanism to help
inexperienced users from getting confused (and there is an escape
hatch mechanism to allow it to those who know what they are doing),
and use of symbolic-ref to make 'main' and 'master' synonyms with
each other is not something inexperienced users who have no clue on
what they are doing would be doing anyway, it may not be a huge
deal.

I also suspect there is no way, other than scanning _all_ the local
branches, to see if some other branch aliases the branch we are
about to check out.  It may potentially be somewhat expensive.

But it would be nice if it can get fixed in inexpensively.

Thanks for a report.


> Below is a minimal reproducer:
>
> $ git --version
> git version 2.36.0
> $ git init .
> $ git status
> $ git commit --allow-empty -m "Initial commit"
> $ git symbolic-ref refs/heads/main refs/heads/master
> $ git worktree add ../worktree2
> $ git worktree list
> /home/amorton/test/worktree1 cd8312d [master]
> /home/amorton/test/worktree2 cd8312d [worktree2]
> $ cd ../worktree2
> $ git checkout master
> fatal: 'master' is already checked out at '/home/amorton/test/worktree1'
> $ git checkout main
> Switched to branch 'main'
> $ git worktree list
> /home/amorton/test/worktree1 cd8312d [master]
> /home/amorton/test/worktree2 cd8312d [master]

Re: Able to checkout same branch in multiple worktrees when using symbolic-refs

[Austin Morton]

By your own definition I am not an inexperienced user (since I am
using worktrees and symbolic-refs), but this has bitten me on enough
occasions to beat me into submission and submit a bug report ;-)

I don't know why you would need to scan all the local branches, unless
that is what "git worktree list" ends up doing under the hood?

"HEAD" in a worktree that was checked out using the symbolic-ref still
contains the symbolic ref name, while the worktree list resolves it.

$ cat .git/worktrees/worktree2/HEAD
ref: refs/heads/main
$ git worktree list
/home/amorton/test/worktree1 cd8312d [master]
/home/amorton/test/worktree2 cd8312d [master]

Seems like you would "just" need to resolve the symbolic-ref in the
same way that the worktree code does when checking against existing
worktrees in find_shared_symref during checkout.

Cheers,
Austin

On Fri, Apr 29, 2022 at 8:19 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Austin Morton <austin.morton@aquatic.com> writes:
>
> > When using a symbolic-ref I am able to inadvertently checkout the same
> > branch in multiple worktrees when using the symbolic-ref name, despite
> > being prevented from doing so if I use the target branch name.
>
> Don't do that if it hurts ;-)
>
> If you checked out 'main' in the secondary worktree and made a
> commit there, the symbolic-ref makes 'master' to be updated,
> confusing the primary worktree whose index and the working tree
> files record work relative to the old commit before the secondary
> worktree updated it via the symbolic-ref, which is exactly the same
> situation that the "do not check out the same branch in two
> different worktrees" protection tries to save the user from, but I
> do not think we currently do so.
>
> Because this "do not check a branch out twice and let it be futzed
> with from the two places" is primarily a mechanism to help
> inexperienced users from getting confused (and there is an escape
> hatch mechanism to allow it to those who know what they are doing),
> and use of symbolic-ref to make 'main' and 'master' synonyms with
> each other is not something inexperienced users who have no clue on
> what they are doing would be doing anyway, it may not be a huge
> deal.
>
> I also suspect there is no way, other than scanning _all_ the local
> branches, to see if some other branch aliases the branch we are
> about to check out.  It may potentially be somewhat expensive.
>
> But it would be nice if it can get fixed in inexpensively.
>
> Thanks for a report.
>
>
> > Below is a minimal reproducer:
> >
> > $ git --version
> > git version 2.36.0
> > $ git init .
> > $ git status
> > $ git commit --allow-empty -m "Initial commit"
> > $ git symbolic-ref refs/heads/main refs/heads/master
> > $ git worktree add ../worktree2
> > $ git worktree list
> > /home/amorton/test/worktree1 cd8312d [master]
> > /home/amorton/test/worktree2 cd8312d [worktree2]
> > $ cd ../worktree2
> > $ git checkout master
> > fatal: 'master' is already checked out at '/home/amorton/test/worktree1'
> > $ git checkout main
> > Switched to branch 'main'
> > $ git worktree list
> > /home/amorton/test/worktree1 cd8312d [master]
> > /home/amorton/test/worktree2 cd8312d [master]

Re: Able to checkout same branch in multiple worktrees when using symbolic-refs

[Junio C Hamano]

Austin Morton <austin.morton@aquatic.com> writes:

[jc: swapped the blocks to chronological order, and trimmed parts
that are not relevant to this reply].

> On Fri, Apr 29, 2022 at 8:19 PM Junio C Hamano <gitster@pobox.com> wrote:
>>
>> Austin Morton <austin.morton@aquatic.com> writes:
>>
>> I also suspect there is no way, other than scanning _all_ the local
>> branches, to see if some other branch aliases the branch we are
>> about to check out.  It may potentially be somewhat expensive.
>
> I don't know why you would need to scan all the local branches, unless
> that is what "git worktree list" ends up doing under the hood?
> ...
> Seems like you would "just" need to resolve the symbolic-ref in the
> same way that the worktree code does when checking against existing
> worktrees in find_shared_symref during checkout.

Yeah, you're right.

You would scan all the worktrees instead of asking all the
local branches "Are you a symlink that points at a branch I am about
to check out?  If so, yell loudly to stop me."

>> But it would be nice if it can get fixed in inexpensively.
>>
>> Thanks for a report.

So, yeah, it may be doable to fix it inexpensively.

Patches welcome ;-)

Thanks.