A design for distributed submodules

I think I finally agree that it's best to develop submodules further rather than introduce a new tool for the functionality I require. Here are some explicit proposals for submodules so we can at least establish agreement on what should be done. These are in order of decreasing importance (to

Re: A design for subrepositories

Quoting Junio C Hamano gits...@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

Re: A design for subrepositories

Quoting Jens Lehmann jens.lehm...@web.de: 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. Your initial statement is not

A design for subrepositories

Hello. I intend to work on a subrepository tool for git, but before I embark on the actual programming, I thought to first invite comments on the general design. Some background first. I know that there are several existing approaches already for managing nested repositories, but none of

Re: A design for subrepositories

Quoting Junio C Hamano gits...@pobox.com: Now the subdirectory repositories are bound as submodules of the top level directory just fine. This is indeed possible, but with some serious caveats. Firstly, if you simply do git submodule add ./foo (the obligatory ./ being quite an unobvious