Re: tracking submodules out of main directory.

From: henri GEIST <henri.geist@flying-robots.com>
Date: Jun 27, 2011, 18:40 UTC
Message-ID: <1309200051.2497.288.camel@Naugrim.eriador.com>
In-Reply-To: <7vvcvrxlol.fsf@alter.siamese.dyndns.org>

First of all thank you for your answer.

Le lundi 27 juin 2011 à 09:51 -0700, Junio C Hamano a écrit :

Show 25 quoted lines

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

Show 10 quoted lines

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

Show 5 quoted lines

> 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