Operating system
macOS
Orca version
1.4.196
Details
Short summary:
Creating a worktree from a Linear issue can fail when its generated branch name contains Unicode and a canonically equivalent branch is already checked out in another worktree.
What happened?
The native Create Worktree dialog sometimes invokes git worktree add with a branch that Git considers identical to an already checked-out branch, then fails with:
fatal: 'feature/수신-기반' is already used by worktree at '/path/to/existing-worktree'
The destination path has already been given a numeric suffix, but the branch name has not, so retrying produces the same failure.
How can we reproduce it?
- On macOS, use a repository with
core.precomposeunicode=true.
- Have a local branch containing Hangul checked out in an existing worktree.
- In the Orca native app, open the Create Worktree dialog and select a Linear issue whose generated
branchName is canonically equivalent to that branch but uses the decomposed Unicode representation.
- Create the worktree.
Expected result:
Orca detects that Git resolves the requested name to an already checked-out ref and follows its existing branch-conflict behavior instead of invoking git worktree add with that ref.
Actual result:
Orca treats the decomposed Linear branch name and the precomposed branch returned by git worktree list as different JavaScript strings, attempts to reuse the occupied branch, and Git rejects the command.
Why it appears intermittent:
The first creation and ASCII-only branch names work. The failure requires both an existing checked-out branch and canonically equivalent Unicode names represented differently.
Additional diagnostics:
- Apple Git 2.50.1
core.precomposeunicode=true- The Linear-provided branch name reaches worktree creation in NFD form.
git worktree list --porcelain reports the checked-out ref in NFC form.git show-ref --verify -- refs/heads/<NFD name> resolves to the actual NFC ref on macOS.
Operating system
macOS
Orca version
1.4.196
Details
Short summary:
Creating a worktree from a Linear issue can fail when its generated branch name contains Unicode and a canonically equivalent branch is already checked out in another worktree.
What happened?
The native Create Worktree dialog sometimes invokes
git worktree addwith a branch that Git considers identical to an already checked-out branch, then fails with:The destination path has already been given a numeric suffix, but the branch name has not, so retrying produces the same failure.
How can we reproduce it?
core.precomposeunicode=true.branchNameis canonically equivalent to that branch but uses the decomposed Unicode representation.Expected result:
Orca detects that Git resolves the requested name to an already checked-out ref and follows its existing branch-conflict behavior instead of invoking
git worktree addwith that ref.Actual result:
Orca treats the decomposed Linear branch name and the precomposed branch returned by
git worktree listas different JavaScript strings, attempts to reuse the occupied branch, and Git rejects the command.Why it appears intermittent:
The first creation and ASCII-only branch names work. The failure requires both an existing checked-out branch and canonically equivalent Unicode names represented differently.
Additional diagnostics:
core.precomposeunicode=truegit worktree list --porcelainreports the checked-out ref in NFC form.git show-ref --verify -- refs/heads/<NFD name>resolves to the actual NFC ref on macOS.