From: Lauri Alanko Date: Sun, 14 Oct 2012 10:19:28 GMT Subject: Re: A design for subrepositories Message-ID: <20121014131928.25943ezwa6fveyls.lealanko@webmail.helsinki.fi> In-Reply-To: <7vzk3p1xh3.fsf@alter.siamese.dyndns.org> Quoting "Junio C Hamano" : >> 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? Yes, and as I showed after the part you quoted, it is possible to refer to a module by name, although it looks like such a hack that I can't imagine it's currently something that git-submodule is intended to support. >> 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? Yes, and I listed three possible ways. Two of them seem technically unattractive, whereas one of them (submodules as ref directories) seems like a huge change that could introduce incompatibilities. That is why a separate tool seems like a cleaner choice. If you want enhancements to git-submodule, at least deign to comment on the issues above. There is actually a fourth alternative: extend the git protocol so that a remote repository could be queried for its list of submodules. But this seems particularly icky: git is at its core such a low-level framework. Nested repositories are such a high-level concept that something is wrong if the core needs specialized support for it. The ref directories approach, on the other hand, is completely transparent to standard tools. Lauri