Re: tracking submodules out of main directory.

From: Jens Lehmann <jens.lehmann@web.de>
Date: Jun 27, 2011, 19:02 UTC
Message-ID: <4E08D3B9.401@web.de>
In-Reply-To: <1309200051.2497.288.camel@Naugrim.eriador.com>

Am 27.06.2011 20:40, schrieb henri GEIST:

Show 25 quoted lines

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