Single or Multiple Git repositories for libraries shared between teams

I am looking at how/if I should make the switch from svn to git.

I currently have a multi-layered set of projects in svn which are layered such that D uses C which uses B which uses A. Actual deployed projects like X,Y,Z use any of the common libraries A-D. The aim is for future projects and other teams to share the base libraries (A-D) and to enable better branching control.

In svn if we wish to allow other teams to use library C without getting involved with X,Y,Z then it is simple, they just check out the C bit of the svn tree, if that leads to them wanting to patch B, then ditto. They never touch X,Y,Z even if they are in the same actual repo. It is not so obvious what happens with git.

If I wish to set something up using git, how would you suggest I set it up and what are the upsides/downsides with your suggested setup.

Features I am looking for are:

  1. Simple tagging (if possible) so can tag the state of the whole codebase easily (simple with a common svn root or a single git repo)
  2. Easy for others to integrate/reuse the common libraries A-D
  3. Simple for them to give us back suggested fixes/patches which we can choose to take or ignore (one of the main things I want from git).
  4. Teams to have effectively private ownership features available for shared libraries (so they can tag them and fix them for themselves on their own timelines)

Git seems to offer what I want, I am just not sure how to deal with the single vs multiple repos problem.

  • How can I remove everything from a remote Git repository?
  • Easy to use revision control for one person
  • Git log for only part of a file?
  • Does git checkout overwrite all files?
  • Git - Pull from one remote repo, push to another: can I push names of remotes?
  • Vim, LaTeX, word-wrapping, and version control
  • How to Manually Deploy a Rails App with Git
  • What does hg copy do?
  • One Solution collect form web for “Single or Multiple Git repositories for libraries shared between teams”

    If I wish to set something up using
    git, how would you suggest I set it up
    […]

    Just go with multiple git repositories (they are quite cheap and they are akin to many small boats instead of a Titanic–in other words, I find that they are flexible and I love flexibility).

    Now and then I assist with a project that is structured like so

    foo/server
    foo/client
    foo/docs
    foo/tools/
    

    The ‘server’, ‘client’, ‘docs’ and every folder in ‘tools’ are separate git repositories. This allows specialized team members to clone and work on exactly what they wish to work on.

    Not to mention, if we just want to pull in everything, we can clone foo (which pulls in the rest as sub-modules).

    It’s awesome that git allows you to do this so why not take advantage of it?

    […] and what are the
    upsides/downsides with your suggested
    setup.

    It’s possible that my suggestion is slightly complex to implement.

    Git Baby is a git and github fan, let's start git clone.