Re: tracking submodules out of main directory.

[Jens Lehmann <Jens.Lehmann@web.de>]

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.