Re: tracking submodules out of main directory.

From: henri GEIST <henri.geist@flying-robots.com>
Date: Jun 27, 2011, 21:45 UTC
Message-ID: <1309211154.2497.391.camel@Naugrim.eriador.com>
In-Reply-To: <4E08D3B9.401@web.de>

Le lundi 27 juin 2011 à 21:02 +0200, Jens Lehmann a écrit :

Show 31 quoted lines

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

Yes that is exactly what I want.

> But "abcdef" might be a direct descendant of "123456" and is
> just fixing a bug that affects only project_2.

Yes but you can not make a rule of this the difference can have any reason. And mare often the bug has a chance to affect both project. In any case both will be improved with a version more correct.

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

Yes that is also exactly what I want.

> That would make the projects not so modular and
> independent anymore and won't scale well.
>

It is sufficiently independent for me.
  - If some one pull only project1 from me he will have a consistent
    library_1 at "123456"

  - If some one pull only project2 from me he will have a consistent
    library_1 at "abcdef"

  - The conflicting version dependency is only in my working directory
    to be solved. And in my work flow updating project_1 to reflect the
    correction in library_1 is the thing to do.

  - If some one decide tu pull from me both project_1 and project_2 in
    the same working tree he will effectively inherit my conflict.
    But that also mean he is working on both project and decide to take
    account of the relation between them like me.
    Then the first one who upgrade project1 will be pulled by the other
    one.

  - In any case if you have no time to update a project an need to
    immediately work on it you always can :

      - Go in the library one directory and checkout the right version
        for the project.

      - Or clone project alone with its libraries in a completely
        separate directory.

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

In this case you could not commit anything until every thing has been done without breaking something.

When committing library_1 to "abcdef" nothing wrong happen in both case all project still point to "123456"

when committing project_2 it will need to point to "abcdef" but in your work flow the super project still say him it point to "123456" and project_2 is broken.

If you immediately commit the superproject to repair project_2 you will brake project_1 until it is also upgraded and superproject is reupgraded to reflect it.

In my work flow when committing project it will immediately point to "abcdef" and not been broken.

project_1 still point to "123456" and is still not broken

superproject which is not needed still point on all old versions and is not broken.

On commit of project1 it will immediately point to "abcdef" an is not broken

superproject will till point on all old versions and is not broken.

On commit of super project if we have one every thing is up to date.

	Henri GEIST