Re: tracking submodules out of main directory.

[henri GEIST <henri.geist@flying-robots.com>]

Le mercredi 03 août 2011 à 10:11 -0700, Junio C Hamano a écrit :
> henri GEIST <henri.geist@flying-robots.com> writes:
> 
> > I plan to use a config file containing lines like
> >
> > "path_to_poited_repo   SHA1_of_intended_commit   URL_of_origin"
> >
> > the URL part will not be required.
> >
> > this file will be a list of pointer to other project.
> 
> I wasn't paying attention to this thread, but I have to ask "why" here.
> 
> The first two are what gitlink was designed to do in the superproject that
> ties multiple submodules together, and the last one is also supplied by
> the .gitmodules in that superproject.

Yes my only problem is that it is forbidden to put a submodule outside
of the repository.
That is way I had done a patch witch enable me to do so and I use it
flawlessly every day. with total satisfaction.

> This seems to be adding the same information in a redundant way by saying
> "this version A0 of submodule A wants version B0 of submodule B and
> version C0 of submodule C" when the supermodule can say "the consistent
> view I record is to have version A0, B0 and C0 of submodules A, B and C,
> respectively".
> 

Exact but my goal is to get ride of the superproject.
This is how I will remove the redondency.
Cause creating a projet just to said to other project what they need is
a wast. Each project has to now by itself what it need.

And each user will have his own list of project to work on.
Then they we will create one different superproject for each user.

One user can work on a superproject containing :
gimp, gqview, libpng

One other will work on a superproject containing :
gimp, gphoto, libpng, libusb

The next one will work on a superproject containing :
xsane, libusb

They can absolutely not share there superproject only the normal
projects.
And if the dependency are defined in superproject, and not in the
projects themselves. Users can not share their dependency constructs.

I have no intend to have "sub"modules but to have generic modules with
no hierarchies only dependence relations. Which could even be crossed.
(Module A require module B and module B require module A.)
Even if in this particular case I do not see the point to make two
distinct modules.


> I also suspect that allowing each submodule to know and demand specific
> versions of other submodules will lead to inconsistencies. Which version
> of submodule C would you demand to have when submodule A wants version C0
> and submodule B wants version C1 of it?
> 

That is already the case with normal submodules.
And of corse if you have a project which recursively depend of to
version of the same library, you need to update it, and it has nothing
to do with git. Git will just make it obvious.


The reason we decide to make a parallel file ".gitdependencies",
containing something really similar to the content of ".gitmodules"
is that in .gitdependencies we will put references outside of repository
and in ".gitmodules" the references inside git repository as actual.

This separation will be done because Jens Lehmann show us
that .gitmodules are lot more that what I expected from those reference
and do not think that the others abilities of submodules should apply to
external modules.

	Henri