Re: tracking submodules out of main directory.

[Junio C Hamano <gitster@pobox.com>]

henri GEIST <henri.geist@flying-robots.com> writes:

> We can obviously solve this by doing trees of submodules just reflecting
> the trees of dependency but it create somme problems.
>
>   1. In project 4 I have 2 times project 1 and 3 times libraries 1 and 2
>      And 2 times library 4.
>   2. It is a wast of space.
>   3. Different version of the same libraries or projects could be used.
>   4. when linking object, multiples objects will export the same symbols

All of the above are something your build procedure needs to solve
regardless, even if you are not using git submodules (or even if you are
not using any SCM, for that matter).  If you want to (and you do want to)
avoid duplication, version drift and associated issues of use of the
common library 1 across project 1 and project 2, you would organize your
source tree so that both of your (sub)projects to use the library code
from a common location.

One possible working tree organization may look like this:

	-+- lib1
         +- project1/Makefile -- refers to ../lib1
         +- project2/Makefile -- refers to ../lib1

The top-level superproject (what you called "Anything") binds project1,
project2 and lib1 as its submodules, and it can say where you want your
users to fetch these submodules in its .gitmodules, and at what version
lib1 (and projects) to use in its tree objects as gitlinks.

People who are _only_ interested in project1 can still clone that
top-level superproject, and "submodule init" only lib1 and project1,
without running "submodule init" on project2.

An interesting point your situation raises is that there is no direct way
to express module dependencies in .gitmodules file right now, I think.
Ideally you would want "submodule init project1" to infer automatically
that project1 needs lib1 and run "submodule init lib1" for you. My gut
feeling is that it belongs to .gitmodules of the superproject.