I suggest you ...

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.

1,975 votes
Sign in
Sign in with: facebook google
Signed in as (Sign out)
You have left! (?) (thinking…)
Neal Culiner shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Sign in with: facebook google
Signed in as (Sign out)
  • Phillip Ross commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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 ?

  • SensorSmith commented  ·   ·  Flag as inappropriate

    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).

  • Richard Petheram commented  ·   ·  Flag as inappropriate

    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.

  • AndersD commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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.

  • Alastair commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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.

  • Vaclav Elias commented  ·   ·  Flag as inappropriate

    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..

  • Anonymous commented  ·   ·  Flag as inappropriate

    Our solution contains multiple projects from different git repositories. Would be great to be able to manage them all within the same VS instance - instead of opening multiple instances of VS or resorting to the command line.

  • Stefan Ingvarsson commented  ·   ·  Flag as inappropriate

    We use submodules and would like full support for them. Some projects are placed in a submodule since they are used by multiple solutions in different repositories.

  • John Preston commented  ·   ·  Flag as inappropriate

    I'd love to see full support for submodules. We have solutions that contain projects from multiple repos managed using submodules (though individual projects do not span repos).

Feedback and Knowledge Base