Re: tracking submodules out of main directory.

[henri GEIST <henri.geist@flying-robots.com>]

First of all thank you for your answer.

Le lundi 27 juin 2011 à 09:51 -0700, Junio C Hamano a écrit :
> 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
> 

I agree on this point.
And that is just what I do and mean by :

>> Anything/library_1
>> Anything/library_2
>> Anything/library_3
>> Anything/library_4
>> Anything/project_1 with a git submodule add ../library_1 ../library_2
>> Anything/project_2 with a git submodule add ../library_1 ../library_3
>> Anything/project_3 with a git submodule add ../library_2 ../library_4
>>                                             ../project_1
>> Anything/project_4 with a git submodule add ../library_4 ../project_1
>>                                             ../project_2 ../project_3

I would like git to do just the same thing that do my Makefile.

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

Until now I did not thought about making "Anything" a git repository.
It was just a simple directory containing all my projects.
And project_4 was not a submodule of anything.

May be I need to think more about it.

But actually it is just pushing the problem one rank more by making
"Anything" a kind of project_5 which contain submodules in sub
directories and will rase the same problem the day project_6 will need
project_5.
And it does not solve the problem of making project_1 knowing is need to
be linked to library_1 in version "abcd1234..."

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

I agree on this point.

> An interesting point your situation raises is that there is no direct way
> to express module dependencies in .gitmodules file right now, I think.

And that is the real problem.
It could be done for submodule inside of the project main directory.
But not for modules outside of it.

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

I do not really care about project_1 doing the submodule init.
I can easily do it by myself.
And in fact I use to write the libraries before the project using them.
then there git repositories already exist

what I really need is to do :

cd project_1
git add ../library_1

then in case of modification in library_1

A git status in project_1 directory will say me :

modified:   ../library_1 (modified content)
or
modified:   ../library_1 (new commits)
or even
modified:   ../library_1 (new commits, modified content)

Just like it do for submodules with out "../" in the path.

And I really think the metadata to do so should be stored in project_1
since it is him which depend on library_1 version "abcd1234..." and this
information need to be self contained.
May be in project_1/.git or project_1/.gitmodules

I do not see the point of having a third party project "Anything" Just
to say to project_1 hey you need library_1.
If it need it, it should already know it.


	Henri GEIST