On Wed, Jul 16, 2008 at 2:38 PM, Johannes Sixt <j.sixt@xxxxxxxxxxxxx> wrote: > Nigel Magnay schrieb: >> P and S aren't distant projects, they're closely coupled. > > And I'm saying that submodules are designed for *loosely* coupled projects. > > It's no wonder that this tool is awkward to use in your workflow. > Ok in a sense. I don't think it's particularly clear from the documentation that this is a limitation of submodules though. Given that - The only way in git to separate out re-usable modules is by the use of submodules and - It's a pretty common usecase for these submodules to be interrelated and - Looking over the list archives, it seems this is quite common complaint "I really like the git submodule implementation, I just don't like how hard it is to work with" "The current behaviour strongly encourages me to avoid submodules when I would otherwise like to use them, just to keep the rest of my team members (who are not git experts) from going insane." "For my use case, I passionately dislike the fact that a submodule is not updated automatically. There's never a time when I don't want to update the submodule. The submodule is a very important piece of our project and the super-project depends on it being at the right version." and - All the technical capability is there, it's just the porcelain that's causing the friction. then would this not seem to be an area that could be improved? Even if it were an optional mode of working? -- 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
