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@xxxxxxxxx> wrote: > > Austin Morton <austin.morton@xxxxxxxxxxx> 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]
