Le mercredi 03 août 2011 à 21:07 +0200, Jens Lehmann a écrit : > Am 03.08.2011 19:11, schrieb Junio C Hamano: > > 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. 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". > > During the discussion this evolved from a simple "I need that submodule > with exactly this version" to something I believe is more generic and > very useful for others. As I see it now a submodule should be able to say: > > 1) To use me, you need another submodule "foo" > > This is very helpful when you want to add the Gimp submodule and it > can tell you you'll need the libpng submodule too in your superproject > (but I'd vote to use the submodule name here, not the path as that > should be the superproject's decision). > > In addition to that, it can (but mustn't) specify any of the following: > > a) Of this submodule "foo" I need at least that version because I won't > compile/work with older versions of that. (this can be tightened to > "exactly that version" to give henri the behavior he wants, but that > should be policy, not mandatory) > Of corse and git will not enforce this policy. Git status will only say the version is unrelated, match or is higher. And it is left to the human reading the status to decide if it is OK with his policy. > Gimp could say it needs at least libpng 012345 because in that version > the function foobar() was added it now depends on. Normally this won't > be updated very often, but if people like henri use that to say "I'll > only promise to work well with that exact version, as that went through > extensive QA" they might change that on virtually every commit. > In fact I do so very rarely I do not update my project to track the last version of the library until the project need it. If the library get new features and improvement that I do not need I keep the old version. I will not rewrite the tones of certification papers to certify the use of the new library version without needs. It will destroy all the forests. > b) And if you don't know where to get it, use this url > > That can give the superproject a hint where it can clone that > repository from. That could be helpful for distributions to sort out > the dependencies of the packages they pull in. > > That is all stuff the submodule knows better than the superproject. And > that information can be used to *inform* the user about the submodule's > needs, maybe using "git status --submodule-dependencies" will print: > > # submodule "Gimp" requests a libpng 567890 or newer > # submodule "foo" has missing dependency "bar" > But the user can choose to ignore that (because he knows he has the png > support disabled and he doesn't need the fancy help files from bar). > > And maybe "git submodule add" learns an option to automatically add all > the other submodules the new one depends on too (for that we would need > the url). > Provided that you use a superproject. But my goal is to eliminate it. > But the superproject is still the place to say: I know these versions of > all submodules work together, so I commit their gitlinks here. But this > scheme enables submodules to give hints to help the superproject's user. > or they can do it by them selves has now they have all the needed infos. > > 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? > > Right, in the discussion so far it seemed like henri seems to be the only > user who is wanting an exact match, and he says he needs to see these > inconsistencies. I suspect I am just the only one you now about. Because that is just what actual submodules does, and nobody complain. If you - cd into one of your submodules - make a commit - go back into the main repository - make git status It will tell you : "modified: the_submodule_name/ (new commits)" Note it actually will say "new commits" even if it is older or totally unrelated. It just signal a mismatch. Then what I need on this point is just what it actually do. > But I think he can modify the "version xxx or newer" to > his needs without imposing these inconsistencies on users (like me) who > don't want to see them. > Of corse git status has never imposed anything. But I will enabling it to make the distinction between unmatched and newer version. 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