On Mon, Jun 21, 2010 at 12:19:02PM +0200, Johan Herland wrote: > > Ah, so Git should automatically _eliminate_ other alternatives based on the > fact that they are not compatible with the purpose of the superproject > merge. Still, that requires Git to know the purpose of the superproject > merge. Which it doesn't, AFAICS. This appears to be a good time to resuscitate an idea we had a while ago: Why not make merging recursive wrt submodules? I have been trying for some time to figure out how to use git for some huge projects that consist of hundreds of more or less tightly coupled modules. Some of these modules are used for multiple projects, and taken together they are too large to fit well into a single repository. I wouuld like to be able to use submodules to achieve several things: 1. Partial clones/checkouts - clone only the modules you need 2. Make git behave for projects that are too large for a single repo 3. Bonus: share some modules between muptiple projects Now - for each superproject I would like this to behave as closely as possible to working with a single repo, so for merging this would mean that any merge from toplevel would automatically do the merge in all affected submodules as well. Just merge the sha1's directly, don't try to be clever - merge as if it was a subdirectory. - 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