Re: A design for subrepositories

["Lauri Alanko" <la@iki.fi>]

Quoting "Junio C Hamano" <gitster@pobox.com>:

>> 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