On Wed, Apr 29, 2009 at 10:27:44PM -0400, Avery Pennarun wrote: > Many projects are made of a combination of several subprojects/libraries and > some application-specific code. In some cases, particularly when the > subprojects are all maintained independently, 'git submodule' is the best > way to deal with this situation. But if you frequently change the > subprojects as part of developing your application, use multiple branches, > and sometimes want to push your subproject changes upstream, the overhead of > manually managing submodules can be excessive. > > 'git subtree' provides an alternative mechanism, based around the > 'git merge -s subtree' merge strategy. Instead of tracking a submodule > separately, you merge its history into your main project, and occasionally > extract a new "virtual history" from your mainline that can be easily merged > back into the upstream project. The virtual history can be incrementally > expanded as you make more changes to the superproject. We have the exact same situation. I wanted to attack this from the other end though, make submodules useable also in this scenario. The subtree solution seems to be much easier to do in git, so maybe this is a better approach! Let's say you have three different projects that all use some shared modules, The following operations should all be easy and fully supported: a) Modify project + some shared modules (in your project) with single commit b) Push project + shared modules (for your project) c) Push modifications to shared modules d) Merge upstream version of shared modules into your project. My quick analysis: Your subtrees: a & b are easy, c & d are painful Current submodules: a & b are painful, c & d are tolerable (somewhat tedious with many shared modules, easy with one) Subtrees also have the advantage that all the existing local tools will be a lot more useful without any modifications (gitk, git gui, git diff/patch/am/log/...) To make subtrees realy useful, it would be good if you could improve c & d, syncing with the shared modules! - Finn Arne -- 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