Allow multiple Git repositories to be active at once
This suggestion is migrated to Developer Community. Please use below link to view the current status.
This description has been modified by the admin.
This request is to have VS allow more than one Git repository be active at once. By allowing multiple repositories to be active at once, one can work with a solution that spans multiple repositories and also view histories and files of a submodule and parent repo at the same time.
We’re excited to let you know that we’ve begun planning for this feature. Please keep an eye out for further updates!
Meisho Shorrosh commented
Hope this comes sooner rather than later!
Connor Stott commented
Really looking forward to getting this update! please keep this on your radar! i would really like to see this out soon!
Brian Vind Borgstrøm commented
VSTS Team - any idea about the release date?
Phillip Ross commented
Ugh. I finally decided to switch over from my visualsvn server to TFS today, built my projects, transferred my code and found out that this wasn’t already a thing. Ugh
Olivier Helin commented
I have 1 team project on TFS with 2 git repositories. Consequently I have to select one of the two GIT repositories and I can't see the "Pull Requests", "WorkItems" and "Build" items.. I hope this improvment will fix it ?
Please support multiple repositories without *requiring* the specific use of git-submodules. Google repo and other solutions are popular as well and can be supported very well just by correctly mapping files/folders upward to the correct repo. That said the main reason git-submodules is not used more often is that it requires a lot of extra steps and a helpful UI so *additional* submodule support would likely be welcomed (just please don't *require* it for basic multi-repo support).
Brian Vind Borgstrøm commented
Is there a chance for letting us know a release date?
Brian vind Borgstrom
Raymond Bergen commented
@VSTS Team where can we follow the progress of this feature?
Richard Petheram commented
2 Use cases:-
1. DTOs shared between server and client. The project containing the DTOs should be on an independent branch, and shared by both the server and the client such that modifications from either solution is reflected in the other.
2. Library under development. Where a library contains code that may be useful to many projects but is being developed in parallel with one or more solutions, the library should be in a separate repository but committed at the same time as other changes.
With great joy I have receved notification that this feature is now entering the planning stage.
Our preferred way of working with VS is a solution containing one website and a number of classliberies supporting that website.
It is much needed to place each web and each classliberie in each own git repo. Letting the developer edit any file in the solution.
For that we need this feature very much.
Please contact me from a reply-able mail adresse or via Skype ID:anders_djursaa for any clarification
Regards and thanks in advance Anders
Stephan Steiner commented
We have a considerable number of library projects (each in its own repo and with its own solution) that are shared across multiple applications. Frequently, the need arises to make changes to one or multiple of these library projects as part of the development of the applications that uses several of these shared libraries. At present, we make the change, then open the solution of the library, check in, switch back to the solution of the application, and continue working there. On SVN (with Anksvh) we were able to update the library projects from the application solution directly (along with all the other source control features - like history, branching, etc.) - that's what we're looking for in Git support in Visual Studio.
Bo Bendtsen commented
We use submodules, and that's is currently poorly support in vs.
Will Calderwood commented
Just copy what JetBrains do... They've nailed it IMO.
We often have a single VS solution that references multiple different projects - quite frequently we want to change a lower down library at the same time as whatever implements that. So having everything including dependencies in one solution makes sense.
But, those are separate components, with their own repositories - or even a single project in another repository along with other projects not being used by the particular solution currently being worked on.
Frequently we like to keep unit tests and harnesses in their own repository, in order not to clutter the main commit history.
Currently, we achieve this through the use of git submodules, but Visual Studio doesn't recognise when submodules are being worked on, and provides no way of interacting with that along with the parent repo.
I would like to see: status icons reflect change status even if the files are in another repository.
A breakdown in Team Explorer showing me which repos have changes to them.
The ability to commit to each repository independently.
The ability to share a commit message across all submodules in one action.
A warning when I commit a parent repository and there are uncommitted changes in sub repos (there is a git feature for this).
The ability to recursively pull submodules when fetching/pulling (git feature exists)
The ability to set parents to either target specific commits in the submodule, or have the submodule track the parent branch (git feature exists, I think).
This needs to coincide with support in TFS, which already seems to support submodules to some extent. There is no point implementing things if the solutions can't then be built. With some more complex dependencies there is the need to faff about with nuget packages to get the build system to recognise that you have separate modules.
Terry Short commented
We have just started using Submodules and encountering all the issues with changing Repos closing the solution and not being aware of changes in the submodule. Intrigued by what the difference between a submodule and a solution containing a project contained in multiple repos?
Simon Gregory commented
We have project references located in multiple repos. Working on these via the IDE is harder than it should be. There's currently no way to see all cross cutting changes and you have to open a VS instance for each repo - because if you change the repo in the master solution then it closes the solution. You only get source control indicators on files in the active repo, so you have to check all related repos for changes to be sure everything's been committed. Have looked into subrepos but these don't quite seem to quite work yet either.
Kristoffer Larsen commented
We both use Submodules, and have large solutions containing multiple repositories. This feature would allow us to work completly in VS, and not having to use a third party for repository management!
Ivan Gilchrist commented
I maintain several applications that share dependencies. Each application has its own package, git repo, and solution file. Each dependency package has its own git repo. I have been including source code files from these dependent packages via solution folders.
Cédric Tallichet commented
@VSTS Team, that is a good news! The "workflow" we are mainly facing is using a main repository with submodules.
Vaclav Elias commented
I work on ASP.NET Core Projects with its git repositories and these projects are sharing some common libraries with its own repositories. And usually these libraries are also in development so when I do any updates and commit projects changes to VSTS I need to commit also my libraries changes. So at the moment I have to do it through another session of Visual Studio where these libraries are open..