Le lundi 27 juin 2011 à 21:02 +0200, Jens Lehmann a écrit :
> 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
--
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