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 us开发者_如何学Ces 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.

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.