Le mercredi 03 août 2011 à 10:11 -0700, Junio C Hamano a écrit : > henri GEIST <henri.geist@xxxxxxxxxxxxxxxxx> 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 -- 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