On Mon, Jul 26, 2010 at 10:56:58AM +0200, Jakub Narebski wrote: > On Sat, Jul 24, 2010, skillzero@xxxxxxxxx napisał: > > git-submodule might be technically possible in this situation, but > > having to commit and push each submodule and then commit and push the > > super module makes it slightly worse than just dealing with the > > space/download/performance issues of one huge repository. > > But this is just a matter for improving UI for dealing with submodules, > isn't it. For example having "git commit --recursive" would help > with 'having to commit each submodule', though how you would write commit > messages then: perhaps supermodule commit message could be by default > composed out of submodules commits (if any). "git push --recursive" > (or some support for push in "git remote") would help with 'having to > push each submodule'. For "recursive" commit, for my own workflow, I would rather have it work like this: from the toplevel, I can 'git commit' any set of files, as long as they all fall inside a particular submodule. That is, if I do git commit mod1/*.c mod2/*.c it should reject it (with a helpful message), because the commit would cross submodule boundaries. But if I do git commit mod1/*.c I think it should create a new commit in mod1, leave my superproject pointing at that new commit, and stop (ie. without the superproject having committed the new commit pointer). Why? Because my normal workflow is: - make a bunch of superproject/submodule changes until they work. - commit the submodule changes with a submodule-relevant message - commit the superproject change with a supermodule-relevant message I wouldn't want to share commit messages between the two, so actually having a single commit process be "recursive" would not do me any good. However, pushing is a separate issue entirely. Having push be recursive would be easy, but it doesn't solve the *real* problem with pushing: git doesn't know what branch to push to in the submodule, and the submodule most likely isn't pointing at a pushable repo at all, even if the supermodule is. This is why I keep coming back to the idea that I really want to push all the submodule objects into the superproject's repo. Have fun, Avery -- 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