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

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

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