On 16 April 2012 13:08, <dag@xxxxxxxx> wrote: > Jakub Narebski <jnareb@xxxxxxxxx> writes: > >> Put reusable library in its own repository, and use submodules to link >> it up to project-a and project-b repositories. > > git-subtree is another option. It was recently merged into contrib/. > Whether to use submodules or subtrees largely depends on the work style > of your group and how coupled the projects are to each other. > submodules requires a bit more day-to-day maintenance by the user (in my > experience) while with subtrees it's a bit more involved to push changes > from the combined repository back to the separate repositories. (My reply below is based on my experience with Git and submodules from about a year ago. I would really like to see better support for including separate repos in Git. It does not appear to be an easy nut to crack, though.) If you really have only one or two libraries then submodules will work just fine but if you have quite a few (we had around 50 when we moved away from submodules) you will find it pretty much unworkable. It's fragile and hard to keep the submodules in synch with each other and the umbrella project. Another problem is branches. Branches are per submodule but you want them for all submodules. You might want to look into git-slave if you want to go this route. I haven't used git-subtree so I can't comment on that. (I do not get the impression that it really is a big step forward, though. I would be *very* happy to be proven wrong, though.) In general, I do not think the blanket statement "one repo per project" is good advice. If projects depend on each other they should be in the same repo. At least with the current support in GIt for including separate projects. Please note that I'm not disagreeing with the notion "one repo per project" itself. It's just not supported well enough to be feasible if you have a fairly large group of projects that depend on each other. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html