Am 27.07.2010 20:40, schrieb Avery Pennarun: > With what you're proposing, for all my submodules, we can't each have our > own project; we all have to push to the shared one. > > (Just to be clear: I don't want to fork *every submodule by hand every > time*. I just want *my* stuff to be in *my* repo. The easiest way to do > this would be to have all my changes in a single repo, ie. my fork of the > superproject.) Fair enough, but that would not be the Right Thing for my use cases. (E.g. I am using submodules to have a single upstream repo for a library which I use in almost all my projects. And fixes to that library I do in one of these projects shall be fetchable in all other projects right after I pushed them to the submodules repo, without having to push them out of the superprojects repo into the shared one /again/. The situation at dayjob is the same and I assume a lot of people are using submodules this way). So I would vote for not breaking the *feature* submodules currently have: to use a different repo than that used for the superproject. Because that enables you to have shared content. I am not against having the /choice/ to have the submodules objects in the same repo as the superproject, but that should be an option and not mandatory. -- 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