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,981 votes
Sign in
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Neal Culiner shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


    Sign in
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      • Tomas Beblar commented  ·   ·  Flag as inappropriate

        We have 1 project (class library) used in 4 different solutions (2 websites, 1 winforms app). Each solution has 2 projects. We need this working. Please get this done asap.

      • Connor Stott commented  ·   ·  Flag as inappropriate

        Really looking forward to getting this update! please keep this on your radar! i would really like to see this out soon!

      • 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?

      ← Previous 1 3 4

      Feedback and Knowledge Base