Describe the bug
When using Add Project → Browse folder to import a subfolder inside a Git repository (for example, a package inside a monorepo), Orca activates the repository's main worktree instead of the selected folder. Both the file tree and the terminal end up rooted at the Git repository root, not at the folder the user picked.
This does not happen when opening the same folder via Finder Services (New Orca Workspace Here), which handles contained paths correctly.
Reproduction
-
Create a Git repo with a nested directory:
mkdir -p /tmp/monorepo/packages/web
cd /tmp/monorepo
git init
git commit --allow-empty -m "init"
-
In Orca, click Add Project → Browse folder.
-
Select /tmp/monorepo/packages/web.
-
The file tree and terminal cwd both show /tmp/monorepo, not /tmp/monorepo/packages/web.
Expected behavior
Importing /tmp/monorepo/packages/web should either:
- open it as a folder workspace rooted at the selected path, or
- reuse the existing
/tmp/monorepo worktree while keeping the terminal cwd at /tmp/monorepo/packages/web.
The current behavior — storing the subfolder as a Git repo but activating the repository root — is inconsistent and confusing.
Additional context
The issue appears to start in isGitRepo, which checks whether a path is inside a Git worktree using git rev-parse --is-inside-work-tree. That command returns true for any subdirectory of a repo, not just the repository root. From there, the import flow stores the subfolder as Repo.path, but git worktree list resolves the main worktree to the actual repository root, so the UI ends up one directory level higher than expected.
PR #5714 already implemented correct handling for Finder Services via resolveWorktreeForContainedPath and createTerminal({ cwd: selectedFolderPath }). The Add Project flow likely needs similar treatment.
Would you like to submit a PR?
Yes — I'm happy to work on a fix and would appreciate any guidance on whether the preferred direction is (a) falling back to a folder workspace for contained paths, or (b) reusing the existing worktree with the selected subfolder as the terminal cwd.
Describe the bug
When using Add Project → Browse folder to import a subfolder inside a Git repository (for example, a package inside a monorepo), Orca activates the repository's main worktree instead of the selected folder. Both the file tree and the terminal end up rooted at the Git repository root, not at the folder the user picked.
This does not happen when opening the same folder via Finder Services (
New Orca Workspace Here), which handles contained paths correctly.Reproduction
Create a Git repo with a nested directory:
In Orca, click Add Project → Browse folder.
Select
/tmp/monorepo/packages/web.The file tree and terminal cwd both show
/tmp/monorepo, not/tmp/monorepo/packages/web.Expected behavior
Importing
/tmp/monorepo/packages/webshould either:/tmp/monorepoworktree while keeping the terminal cwd at/tmp/monorepo/packages/web.The current behavior — storing the subfolder as a Git repo but activating the repository root — is inconsistent and confusing.
Additional context
The issue appears to start in
isGitRepo, which checks whether a path is inside a Git worktree usinggit rev-parse --is-inside-work-tree. That command returnstruefor any subdirectory of a repo, not just the repository root. From there, the import flow stores the subfolder asRepo.path, butgit worktree listresolves the main worktree to the actual repository root, so the UI ends up one directory level higher than expected.PR #5714 already implemented correct handling for Finder Services via
resolveWorktreeForContainedPathandcreateTerminal({ cwd: selectedFolderPath }). The Add Project flow likely needs similar treatment.Would you like to submit a PR?
Yes — I'm happy to work on a fix and would appreciate any guidance on whether the preferred direction is (a) falling back to a folder workspace for contained paths, or (b) reusing the existing worktree with the selected subfolder as the terminal cwd.