Hi, On Mon, 4 Jan 2010, Heiko Voigt wrote: > Johannes wrote: > > The real problem is that submodules in the current form are not very > > well designed. For example, a submodule being at a different commit > > than in the superproject's index is not as fatal as the submodule > > having changes. > > > > So in the long run, IMHO a proper redesign of the submodules would not > > make only a little sense (it does not help, though, that those who > > implemented and furthered the current approach over other discussed > > approaches do not use submodules themselves -- not even now). > > Do you mean the complete workflow (submodules are links to other git > repos) or the current implementation? Do you have links to other design > approaches/threads? Would be nice if we could take that into account for > any decision. Unfortunately, I do not have any information about different approaches except the approach Subversion takes. While Subversion's externals are not perfect for all applications, for some, they are. So I consider this a serious shortcoming that Git does not support that workflow (and in fact, AFAIR Shawn's repo does not use submodules for that exact reason). But I think that an important precondition to come up with a better design of the submodules is to have suffered the current implementation in real-world work using submodules. (Which reminds me very much of the autocrlf mess.) Ciao, Dscho -- 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