Support nested repository discovery via depth limit setting

[markm77]

It would be great to be able to specify a root folder in the .code-workspace file and then VS Code automatically pick up the repo folders contained therein without needing them to be explicitly specified and updated in the .code-workpsace file. This would allow repos to be added and removed far more easily.

Combining this with #87887 could then allow e.g. the following Main Folder to be specified and immediately produce a workspace with appropriately grouped repos....

Main Folder
|--Repo Source or Group 1
    |--Repo 1.1
    |--Repo 1.2
|--Repo Source or Group 2
    |--Repo 2.1
    |--Repo 2.2

[markm77]

FYI here's an actual example of a workspace with multiple repos like mentioned above. The workspace repo names completely mirror the folder structure and it's a maintenance burden keeping the workspace in sync with repo additions and removals which happen reasonably frequently.

It would be nice to specify the search depth (e.g. 2 folder levels) and let VS Code find/update the repos e.g. on launch. I think this feature would be complementary to the list of hard-coded repos (folders) currently supported by the workspace file.

[markm77]

A final comment. One way to implement this would be to support search_folders (detected repos) alongside folders (hard-coded repos) in the .code-workspace file. Each search folder could include the search root name, search root path, search depth and perhaps a choice whether in the Explorer to display repos with tree expansion or a naming delimiter like " / " as shown in the example above.

(I also see no reason why the search folder concept could not be later extended to allow detection of nested repos (up to search depth) with a boolean switch for allowing nested folders (repos). I do not need this but write it having looked at #37947.)

[joaomoreno]

Git currently only detects repositories which might be immediate children of the root folder. Would a setting to control the folder depth of searching for repos work for you?

[joshbmarshall]

This is interesting, and I have been following #37947 and the behaviour I see is:

• If the folder is inside a repo, it loads that repo only, regardless of subfolders containing repos
• If the folder is not inside a repo but has subfolders containing repos, all those repos are loaded
• If the folder is not inside a repo and has subfolders of subfolders containing repos, no repos are loaded

For my use case, I have a number of subfolders nested maybe 3 or 4 levels down, due to being autoloaded (e.g. php composer, npm node_modules) and as they are actively developed at that location it's good to have the git repo loaded.
As the top level project is also source controlled in a repo, vscode does not search for repos in subfolders.

If vscode could search for all repositories in all folders regardless of whether it is already inside one, that would solve my use case, this issue, and #37947 .

So @joaomoreno yes having the folder depth deeper would work and having a setting if required for performance, but it would have to also keep searching deeper for repos inside repos it finds.

[markm77]

Git currently only detects repositories which might be immediate children of the root folder. Would a setting to control the folder depth of searching for repos work for you?

Absolutely, I think a limited search depth is totally appropriate.

[joaomoreno]

The rules of discovery for repos are:

• Currently opened folder and immediate subfolders
• All folders of a workspace and immediate subfolders

repos inside repos

We don't currently support this, it is tracked by #37947

[markm77]

I realise perhaps I can be more clear about what I am trying to suggest by this feature. The idea is to traverse a tree to detect repos/folders in a workspace via presence of (say):

• any file
• .vscode folder
• .git folder

This would save specifying folders manually in the .code-workspace file.

It would allow e.g. addition and removal of repos in a workspace without a need to constantly change the .code-workspace file.

Detection of nested repos would be a bonus feature but really auto-detection of folders in a non-nested arrangement is my main use case.

[joaomoreno]

We currently don't traverse a tree for performance reasons. That's why I asked whether a numeric depth limit setting would make sense. Let's go with that.

[vscodebot]

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[markm77]

We currently don't traverse a tree for performance reasons. That's why I asked whether a numeric depth limit setting would make sense. Let's go with that.

Sure, traverse probably the wrong word as definitely understand the need for a search depth.

[parsley72]

Just created #93697 and the bot flagged this as similar. It would be good if we checked for a git-repo before searching the tree.

[DylanYoung]

Just leaving a note here. My issue (#82378) was closed as a duplicate and I think it might be this issue that was the duplicate.

Let me know if I'm mistaken! The original issue was locked before anyone identified the actual duplicate issue.

[markm77]

For information, Sourcetree on macOS has a feature for adding Repos via "Scan Directory". GitHub Desktop allows dragging in a directory of Repos but I don't think it will search sub-directories. The goal here is (ideally regular, automated) directory scanning to maintain an up-to-date Repo list and the avoidance of having to continually update .code-workspace each time Repos are added (cloned) or removed. For people with lots of Repos who manage them in VS Code this will be a huge help.

[mozhuanzuojing]

@lszomoru Hi, is it possible to exclude node_modules、lib、build、bin、out、target、dist、**/.* when scanning directories.
Thanks.

[lszomoru]

The latest Insiders release contains a new setting - git.repositoryScanMaxDepth (default value of 1) - that can be set either in the user settings or in the workspace settings to control the max depth that is being used when discovering repositories.

@mozhuanzuojing, yes, I think it makes sense to add another setting to control a list of folders that would be excluded from the repository scanning.

[gogobd]

This setting didn't solve it for me; i'm currently following (#37947), too.