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@xxxxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html