# What did you do before the bug happened? (Steps to reproduce your issue)
Clone a repo
Create an additional worktree for that clone
Use `git checkout -B branch-of-primary-clone ...` to checkout the
branch that is already checked out in the primary clone
For example, with the pathfinder repo on GitHub:
git clone https://github.com/servo/pathfinder.git primary
cd primary
git worktree add -b metal ../secondary origin/metal
cd ../secondary
git checkout -b main #reports a fatal error, as expected
git checkout -f main origin/main #also reports a fatal error, as expected
git checkout -B main origin/main # ----> this succeeds, which is
unexpected <----
# What did you expect to happen? (Expected behavior)
I expected a fatal error stating that the branch could not be checked
out since it was already checked out in my primary worktree
In `git checkout --help`, it is documented that `git checkout -B` is
the atomic equivalent of `git branch -f <branch> <commit> ; git
checkout <branch>` :
> If -B is given, <new-branch> is created if it doesn’t exist; otherwise, it is reset. This is the transactional equivalent of
>
> $ git branch -f <branch> [<start-point>]
> $ git checkout <branch>
# What happened instead? (Actual behavior)
The branch was checked out in the secondary worktree. If I then work
and make commits in this secondary worktree, the status of my primary
worktree gets clobbered as well.
What's different between what you expected and what actually happened?
The checkout in the secondary worktree is allowed, but it shouldn't be
[System Info]
git version:
git version 2.41.0
cpu: arm64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
uname: Darwin 22.6.0 Darwin Kernel Version 22.6.0: Wed Jul 5 22:21:53
PDT 2023; root:xnu-8796.141.3~6/RELEASE_ARM64_T6020 arm64
compiler info: clang: 14.0.3 (clang-1403.0.22.14.1)
libc info: no libc information available
$SHELL (typically, interactive shell): /bin/zsh
[Enabled Hooks]
