Git: Support nested git repositories

[javier-moreno-tridonic-com]

• VSCode Version: Code 1.18.0 (dcee2202709a4f223185514b9275aa4229841aa7, 2017-11-08T21:22:49.932Z)
• OS Version: Windows_NT x64 6.1.7601
• Extensions:

Extension	Author (truncated)	Version
cpptools	ms-	0.14.0

---

Steps to Reproduce:

We use some command line tools from ARM to organise our project. This tools rely on special lib files to establish dependencies between modules. Each module should be an independent repository (git repositories in our case). So once all the references are deployed (the tools will "git clone" the indicated repositories in the lib files) the folder structure would look like this (folders in bold):

• project_folder (git repo)
  • module1.lib
  • module2.lib
  • module1 (git repo)
    • module3.lib
    • module3 (git repo)
  • module2 (git repo)

If we add project_folder as the root folder, the source control tab will only track the changes done in project_folder.

If we use the new multi-root project feature and also add module1, module2, and module3 to the workspace; we still find that only the changes in project_folder are tracked.

Nevertheless, if we add the folder in an strict reverse nesting order in the following manner:

1. With an empty project open module3 as root folder
2. Add folder to workspace... module2
3. Add folder to workspace... module1
4. Add folder to workspace... project_folder

Then we see that the source control view displays the several source control providers correctly.

Reproduces without extensions: Yes

[yh-sb]

Is there any updates about this bug?

[sveinse]

Thank you @javier-moreno-tridonic-com for the procedure in how to circumvent this issue by adding the projects to the workspace in inner->outer order. That helps a lot until this issue is fixed.

[mahmoudajawad]

The reverse order works, but screws up intillisense. My python modules from the child folder won't be able to access parent folder package causing all my child package modules to report errors of undefined module. I'd suggest adding settings value to the workspace file where it would automatically populate at generation time all the auto-detected git repos. Then, we can manually set the additional paths for the nested git repos we are using.

[zurkoxxx]

Had the same problem. Fixed it by adding nested repository as a submodule (https://git-scm.com/book/en/v2/Git-Tools-Submodules)

[mahmoudajawad]

Some use cases defy the use of submodules.

On Thu, 11 Oct 2018, 13:53 zurkoxxx, [email protected] wrote:

Had the same problem. Fixed it by adding nested repository as a submodule ( https://git-scm.com/book/en/v2/Git-Tools-Submodules)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Microsoft/vscode/issues/37947#issuecomment-428893510, or mute the thread https://github.com/notifications/unsubscribe-auth/AATVPqDP4H1nHVvdc94usfZI-QQq4j2uks5ujxUcgaJpZM4QX_sw .

[rhymu8354]

In all my work, I have nested git repositories that are specifically not submodules, and for this reason: I want the top-level repository to track each sub-level repository via branch, not commit. I made a Python tool, mugit, which uses a manifest file to maintain the relative repository structure, similar to how Google organizes the Android multi-repository structure using their tool, repo.

Android Studio is notable for handling nested, non-submodule, multi-git repository structures quite nicely. It would be great if VSCode could do the same. In the mean time, I've been using the GitLens extension for most things, but still for making commits I'm pretty much forced to use another tool completely (e.g. git, git-gui, GitHub Desktop, SourceTree, etc.) to stage commits.

I'll be watching this issue with interest. I was disappointed to see there were at least two previous issues filed for this exact same subject, but were closed in the belief that multi-repository support was somehow either already done in some "insider" build (36250) or would somehow ride on the coattails of the multi-folder workspace support (12564).

[rahman]

+1 for nested git repo support

[RobertoSnap]

Is this still only possible with submodules? @rhymu8354

In that case +1 for nested git repo support

[p3t3r5]

could be a workaround for you... I have created .gitmodules in the root of main repo with a content: [submodule "your_module_name"] path = relative/path/to/repo url = git/url/to/repo

Ignore the file in .gitignore, if needed. Its not realy configurated submodule, but VSCode can handle this. Its works recursively to.

VS Code v1.30.2 Git 2.20.1

[benlindsay]

@p3t3r5 Thanks for this info! This feels like kind of a hack, but it's a good interim solution until repos in subdirectories are supported.

For anyone using this .gitmodules hack with no intention of using submodules, also note that the url = line, while necessary for this hack to work, does not require a real URL. Based on some quick testing on my macbook, it looks like any non-whitespace string will work. (I currently have it working with url = dummy_string_to_satisfy_vscode)

[Morgy93]

Any news on this? 🙏 I'd love to have one of these options, maybe one is easy to implement:

main_repo/* <- Git1
main_repo/vendor/module1 <- Git2
main_repo/vendor/module2 <- Git3

(Pretty common for like php composer stuff)

A) Get the current path from terminal The git integration checks the current path upon refresh. So it uses Git1, but if I'm cd main_repo/vendor/module1 then it shows me Git2 instead

• Probably not easy because of different shells and stuff

B) Use the current selection from the explorer The git integration uses the current selected path upon refresh So as long as my selection is somewhere inside of Git3 this will be used for git integration:

C) Set the current git path Slightly different from B) if the "use current selection" is difficult: Just right click and "set this as git path" so that this folder/path is used for the git integration.

For me it seems that the git integration does just like git status and this is of course always from the root of the opened folder. If you could set a git path manually (via right click and select [C] or just use selection [B]) you could simply "add a prefix" do thinks like: cd PATH && git status (there are probably better ways but it would work)

I hope at least one is able to understand this mess 😁 Not being able to simply/quickly select/use a nested repo sadly is a deal breaker for me.

[benlindsay]

Did you try the solution above where you make a .gitmodules file as though you were going to use submodules but don't actually check it in? It's not ideal but at least it's a one time setup that allows integration of all your git repos

[Morgy93]

@benlindsay I work on like 20 of those "main repos" and all of them have like 20 sub git repos which also have dependencies and my co-workers use those main repos as well, so I cannot track what sub repos are added. I'd love to use a workaround, but this one is sadly not maintainable for me.

[benlindsay]

Ah yeah I can see that wouldn't work for your use case.

[TheHackmeister]

@Morgy93 I had a similar use case. My workaround was to create a script that would generate the .gitmodules. Still have to kick it off manually, but WAY easier than by hand. It works by searching for all the folders it needs to include, and then appends them to the .gitmodules. I just needed to loop over all the subfolders in a specific folder. I doubt you're that lucky. Maybe you could adapt this to use find and search for .git folders?

https://github.com/SciFiFarms/TechnoCore/blob/8db3a1cb76f1be6cc4fb1449dc7245532bdbedeb/bin/generate_gitmodules#L1-L17

[JDDoesDev]

I was able to get this working with the submodule hack as well, however there is an issue with order of submodules.

Here's my scenario: I have a local dev environment, Docksal. I want to be able to customize it so it's a repo. I have a Drupal 8 codebase that I use for contribution and development. This lives at /docksal/docroot. This is a repo so I can patch and test. I have a custom module that I've contributed back to d.o. This lives at /docksal/docroot/modules/custom/my_module and is also a repo.

If I have the .gitmodules file list docroot before my_module, SCM doesn't pick up on my_module. If I have the .gitmodules file list docroot after my_module, SCM finds them both.

A bit of a gotcha, but it's worth noting if anyone else finds their way to this thread.

[michaelmcandrew]

Elephant in the room: you can get around this without using (fake) git submodules if you use VScode workspaces as outlined by the OP, as long as you list the folders in order of nested ones first, as the OP outlined.

IMO, a *.code-workspace file makes the intention clearer than creating and gitignoring a fake .gitsubmodule file.

[JojoS62]

I ran into the same problem. I have a project root and some subdirs with own .git. These are shown properly when VSCode starts in the project root. I run the command 'Git: Initialize Repository' and it still works, the root git is added to the repo list. Then I close and repoen VSCode and now only the git for the root is shown. This looks like a problem with the enumeration of the git repos, when there is one found the enumeration for the subdirs is aborted.

[jasomimo]

It would be great to have nested Git repositories support. I am having same issue, where we have main repo, which contains widgets, where each widget is separate Git repository.

[arterrey]

+1 that is a very needed feature. It is quite common for build tools to checkout other repos, it would be nice to be able to edit and commit to dependent repos using the UI

[eine]

I believe that #76904, which is now a candidate for Backlog, would provide a solution to this issue. Hence, I would like to ask users that upvoted this issue to react to #76904 too.

[joshbmarshall]

@eine I did look at #76904 however that is not for nested repo's so would not be any different than having multiple folders in the workspace. So unfortunately not a solution to this issue.

This issue is about having multiple repo's as subfolders in the workspace. I have found making a .gitmodules file in the workspace root a reasonable workaround until this issue is addressed.

[eine]

@eine I did look at #76904 however that is not for nested repo's so would not be any different than having multiple folders in the workspace. So unfortunately not a solution to this issue.

It is for nested repo's, as long as each folder defined in the workspace file is expected to be an isolated domain. Precisely, that's the nuclear feature of #76904. Currently, it is possible to add subfolders (either submodules or nested repos) as additional folders in the workspace, but things are screwed up. #76904 makes it explicit that content in say module1 needs to be tracked independently from the parent.

[joshbmarshall]

It is for nested repo's, as long as each folder defined in the workspace file is expected to be an isolated domain.

Unfortunately you're saying that for it to work with nested repos we would have to list them all in the workspace. There are projects that have many repos that change often and can be cumbersome to add / remove manually. There is a workaround for the nested git repositories at the moment - a dummy .gitmodules file. #76904 would just be another workaround for this issue. Autodetection of nested git repos is the best option. I have added some notes at https://github.com/microsoft/vscode/issues/87888#issuecomment-574949683 on the current behaviour and what behaviour changes we require to get this resolved.

[eine]

@joshbmarshall, that's correct. I did not claim #76904 to be the solution to this issue, nor that it should be superseeded. I just said that it can provide a solution, and asked other users for help to avoid having it closed.

[nandorojo]

This bug still persists. Wondering if there are any plans to support nested git repos. Thanks!

[sveinse]

Are there any plans on fixing this issue?

Due to the presence of the git top repo, the git.scanRepositories and git.detectSubmodules settings are completely ignored. This implies that either .gitmodules or adding folders inner>outer must be done to use them recursively VSCode. This issue is described in #96372

[Jibbajabbafic]

+1 I would also like to see this issue fixed without needing to use hacky workarounds.

[aarograh]

I'd also like to see this work as well, but I think I did find another workaround that's pretty clean (at least for those on unix-based systems):

1. Do not clone the nested repositories inside the parent repository; clone them next to the parent repository
2. Create a symbolic link to the nested repository at the location in the parent where you would normally clone the nested repository

I stumbled upon this in my project because I cloned 8 sub-repositories and sym-linked to a ninth, then noticed the sym-linked one was showing up in VS Code. So I moved all the others and linked to them, and now they show up as well! Just wanted to post that here in case it might be of help to someone else.

[ramyhhh]

Well, +1 I think nesting git repos is good to still be able to use monorepo at the same time make it modular and avoid sharing every app with all the teams