Am 27.06.2011 20:40, schrieb henri GEIST: > 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. The point is it avoids ambiguity and cross-dependencies. If you have project_1 requesting the version "123456" of library_1 and project_2 wants "abcdef", you'll always have one project disagreeing (= being dirty). But "abcdef" might be a direct descendant of "123456" and is just fixing a bug that affects only project_2. So it would be ok for both to have "abcdef", but you'll have to add an extra commit to project_1 saying "updating library_1 because of bug in project_2" to make it clean again. That would make the projects not so modular and independent anymore and won't scale well. If the superproject records these dependencies you just update library_1, run all tests (including those in project_1 & project_2) and commit that in the superproject. -- 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