Repository navigation
Github clone in project should work from parent directory #2852
Description
Activity
I retried this and created an empty project directory to clone into and got a gh error message:
Source control repository operation cloneRepository failed for unknown: Destination path already exists and is not empty.It seems like a) there should be a better user-facing message for the underlying command failing and b), the actual path selected is not being passed to
gh(?) under-the-hood. If I find time I may file a proper bug report instead.you're supposed to put in the full path:
CleanShot.2026-05-29.at.16.14.56.mp4
open to adding support for cloning with inferred dir as another alternative
PR #5989 implements this.
The clone step now proposes the selected folder plus the repository folder, so picking
~/CodeforsHtev/myrepoproposes~/Code/myrepoand the "Destination path already exists and is not empty" error goes away.A few niceties that came out of it:
- It works from a provider lookup (
owner/repo, including Azure DevOpsorg/project/repo) and from any pasted git URL:https://host/owner/repo.git,https://host/owner/repo,git@host:owner/repo.git,ssh://git@host:22/owner/repo.git, with or without a trailing slash, a query or a fragment. The.gitsuffix is stripped. - The repository name stays pinned while you browse: clicking
Documentsgives~/Documents/myrepo, so you keep picking the parent folder and never retype the name. - The folder list ignores the pinned name, so it stays populated. Text you type yourself still filters, and still wins.
- A link that names no repository, like
https://github.com/orssh://git@host:22, proposes nothing and falls back to the browsed folder. - Web and mobile both do it.
- It works from a provider lookup (
- locked and limited conversation to collaborators
on Aug 15, 2026
This may be opinion rather than a bug (hence not submitted as a bug report), but when I was creating a new project by cloning from a GitHub repo, the UI wanted the clone directory to already exist (or at least that's how I interpreted the error message).
I would expect this to work like CLI
git cloneworks, and to create the directory the repo files (and presumably the project files - this is my first project) live in as part of the clone operation. I.e., if I want a project cloned fromsHtev/myrepoto live under~/Code, I should be able to select that directory in the Clone window and my project to clone into~/Code/myrepo. If this is the intent, then maybe this is a bug (Intel Mac user here).