Git submodule support

[stofte]

• VSCode Version:
  1.2.1
• OS Version:
  Windows 8.1 x64

Steps to Reproduce:

1. git clone --recursive repo-with-sub-module
2. code .
3. Edit file in the submodule folder and save
4. Change to git panel
5. Click the changed file
6. VS Code warns "Can't open this git resource."

Is there support for this handy git feature?

[komakino]

@joaomoreno Any news or comments about this? Right now Code beats Atom, Brackets and Sublime in speed(except for Sublime), git integration, usability and lots of other stuff, but the lack of support for git modules renders it unusable for my team.

[joaomoreno]

Nothing.

[mwolfhoffman]

Hey, Looks like I just solved this problem with a little experimentation. I'm using VS Code and could resolve all of my merge conflicts, except one file wouldn't open and just said "Can't Open This Git Resource". This was a new file I was merging into master from another branch, so it wasn't that it was a conflict but it just didn't exist on the other branch. I went ahead and staged the change then synced and it worked fine.

[kkukshtel]

Seconding sub-module support. VSCode is great otherwise but would love to see diffed files from included submodules (and even ability to push).

[xoniq]

Also want to request this feature. Had to disable Git support in VS Code because I need this in most of my projects, without it the Git support is useless.

[chrisjimallen]

+1 for submodule support.

[ZLima12]

+1 as well, it doesn't seem like Code can see node.js packages if they are in the submodule's root. (I am using TypeScript).

[kc-curefit]

+1 much needed for any large size project

[mateuszlewko]

+1 It's a really needed feature. Is there any chance we will see it near future?

[nkev]

+1 For most cases, this would make dedicated Git GUI Clients redundant when using Vs Code

[franky47]

How does this interact with the newly proposed SCM API in #2824 ? I also use git submodules a lot and have to rely on an external tool or multiple VSCode windows, which is a pain.

[LPCmedia]

+1

[antoine-pous]

This feature is a basic usage of git, i really don't understand why the project maintainers haven't yet implemented it. Maybe they don't use anymore VSCode at work?

[jens1o]

@antoine-pous Feel free to provide a pr. :)

[daljaz]

+1 for submodule support

[Luckymoep]

+1 we need submodule support :)

[evgenykovalyov]

+1

[unixs]

+1

[jhasse]

Please use GitHub's "+1" reaction for the first post instead of posting +1.

[dmythro]

I'm really confused that it's not supported yet.

[erickarr]

+1

[petkahl]

So, for those of you who are requesting this, what does git submodule support look like? I've never used it much, but have started, so I was thinking of trying to implement it here.

[erickarr]

Inside a project, particularly one versioned with Git, you have add 'submodules', which are direct links to additional Git repositories. One may be using such a repository, as a dependency within their own project. You may also be a contributor to said submodule.

When you open a project in VS Code, it shows you the Git versioning for the current project you have opened. From there you can view your change history, make commits, etc. Often, you do development within your submodules too. Ideally, you would be able to change to that submodules directory, and view the change history make commits, etc. Currently there is no support for doing so.

[petkahl]

@erickarr, so would automatically opening submodules similar to the way multiple git repositories are opened when you open a folder above them satisfy the need, for the most part? You still have to context shift to perform operations on these separate repositories, but you don't have to leave the editor?

[erickarr]

@petkahl Yes, exactly. As people have mentioned previously, currently when you click on the folder to open it, you get a 'Unable to open 'Specified Folder Name': File is a directory' error.

It would be awesome, to click on your submodules folder name, jump in there, make your commits etc., and jump back out. Because the developers have truly done a good job with the Git integration in VS code (compared to many alternatives), but the ability to do the same within submodules is missing.

[petkahl]

You're talking about the folder name in the source control context, not the Explorer, right?
My thoughts were:

• When a repository is opened, it should scan for submodules in it and open those repositories as well (actually, I have this working already, although it looks like I lose the context menus for the Explorer view. I'm hoping that's just configuration)
• Clicking on a changed submodule should do something useful, rather than "Error: Unable to open 'Submodule (Working Tree)': File is directory." Perhaps open that submodule's repository? Or if that's not possible, maybe just do nothing?
• Maybe show changed submodules with a special icon to signify they are submodules? Or in a special group, or even both?

I like the idea of submodules having a sort of tree structure, and when you're in a submodule, show a ".." submodule that is actually the parent. But as far as I can tell, there's no way to open a particular repository programmatically.

[petkahl]

If anybody's interested, https://github.com/petkahl/vscode/tree/git-submodules contains the first pass at my first bullet point above. I'm going to see if I can address the second one, at least, before I make it a pull request.

[easyrider]

+1

[johnnyhuy]

This can technically be done with a new feature introduced, multi-root workspaces.

Just add folders including sub-modules to the workspace (File -> Add Folder to Wordspace...) and both repositories should appear on the source control menu.

[cassmtnr]

@johnnyhuy Awesome, gonna test this

[nunovieira]

@johnnyhuy Multi-root Workspaces doesn't fix this. In projects with git submodules, details of the submodules don't show on the Source Control pane. It treats the submodule as a file.
We should be able to select each submodule in the SOURCE CONTROL PROVIDERS section and act on it, like we do with the "parent" repository.
Git status in File Explorer and other Source Control goodies should also work with git submodules.

This is a must-have for any project that uses git submodules.

[petkahl]

What's interesting is, when trying to use Multi-Root workspaces as a workaround, it is very significant what order you add the folders. In my experience, if you add the submodules first, then they show up in the source control pane, but if you add the parent folder, it never shows up. If you add the parent first, it shows up, but none of the submodules ever show up, probably because of the way it searches for repositories.

#36313 is a pretty solid fix for this, hopefully it'll work its way through the process and get included.

[awidjaja]

git subtree is better than git submodule.

Would it be possible to add the git subtree command in the git menu list item?

[BenjaminAbt]

subtree is maybe better for you - but not for all.
submodules are more common here.

[petkahl]

@awidjaja that sort of request seems pretty far from the scope of the request here. I'd search for and/or create a separate issue for it.

Edit: I see you did that already, #39152

[joaomoreno]

Thanks to @petkahl (#36313), basic submodule support has landed in master (1ab3fd8)! 🎆

A bit more details:

• Submodules get an explorer decoration
• Submodules appear as separate repositories in the SCM view
• Submodule HEAD changes appear in the outer repository's status list; you can click them to see the diff which shows the HEAD change
• You can stage, unstage and revert submodule HEAD changes

We still need submodule management features (add, remove, update, init), but since the basic support is in, I'll close this and wait for feature requests!

[ultra2]

How can I use it?

[petkahl]

@ultra2, it just makes the submodule git repositories show in the source control sidebar (and highlighting in the file explorer). You still have to manage the submodule creation and init from the command line.

[white-hat]

@ultra2 the problem that it actually does not. I have several git repos with submodules, and I do not see behavior similar to a GIF above. while Sourcetree recognizes the submodule and allow to work with it as a repo, vscode does not do that. It does not mark submodule with 'S' in explorer, it tries to update submodule's root folder and fails with an error
Unable to open 'common (Working Tree)': File is directory. where common is a root folder of the submodule.
I have 1.19.2 installed for MacOS

[nunovieira]

It's available on 1.20.0-insider.