"Lauri Alanko" <l...@iki.fi> writes: > Firstly, if you simply do "git submodule add ./foo" (the obligatory > "./" being quite an unobvious pitfall), you get something quite > fragile, since now we have submodule.foo.url = ./foo. If the > submodules ever get reorganized and foo is moved to ./bar, then it is > impossible to check out older versions or alternate branches, since > the submodule is no longer where it is expected to be at the origin.
Isn't that exactly what the "module name" vs "module path" mapping in .gitmodules file is meant to address? > But still, "git submodule update" only looks at the modules in the > currently checked-out tree. If we have other branches or old tags that > refer to other submodules, there's no simple way to fetch those, too. Didn't I already suggest you to think about how you can improve existing "git submodule" to suit your use case better? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
