{"thread":{"id":"27708","subject":"tracking submodules out of main directory.","startedAt":"2011-06-27T13:07:36Z","lastAt":"2011-08-05T02:19:17Z","messageCount":47,"participants":["henri GEIST","Junio C Hamano","Jens Lehmann","Alexei Sholik","Heiko Voigt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"170571","messageId":"1309180056.2497.220.camel@Naugrim.eriador.com","threadId":"27708","inReplyTo":null,"subject":"tracking submodules out of main directory.","fromName":"henri GEIST","fromEmail":"henri.geist@flying-robots.com","sentAt":"2011-06-27T13:07:36Z","receivedAt":"2011-06-27T13:07:36Z","isPatch":false,"sender":{"key":"henri.geist@flying-robots.com","avatar":null},"body":"Hello,\n\nHere is my topic.\n\nIs it possible to track a submodule through a relative path outside of a\nsubmodule ?\n\nThe purpose of this thing is to maintain dependency through different\nlibrary or projects.\n\nLet says this generic dependency tree.\n\n\nproject 1 --+--> library 1\n |\n +--> library 2\n\n\nproject 2 --+--> library 1\n |\n +--> library 3\n\n\nproject 3 --+--> library 2\n |\n +--> library 4\n |\n +--> project 1 --+--> library 1\n |\n +--> library 2\n\nproject 4 --+--> library 4\n |\n +--> project 1 --+--> library 1\n | |\n | +--> library 2\n |\n +--> project 2 --+--> library 1\n | |\n | +--> library 3\n |\n +--> project 3 --+--> library 2\n |\n +--> library 4\n |\n +--> project 1 --+--> library 1\n |\n +--> library 2\n\nCAUTION : this is a tree of dependency not directory.\n\nWe can obviously solve this by doing trees of submodules just reflecting\nthe trees of dependency but it create somme problems.\n\n 1. In project 4 I have 2 times project 1 and 3 times libraries 1 and 2\n And 2 times library 4.\n 2. It is a wast of space.\n 3. Different version of the same libraries or projects could be used.\n 4. when linking object, multiples objects will export the same symbols\n\nPoint 2 could be acceptable in little project.\n\nPoint 4 could be addressed by a careful compilation schema.\n\nPoint 3 could be no issue and discard point 2 meaning if it is what you\n want in your work flow.\n But in my work flow it is a bug every thing NEED to be\n synchronized.\n\nwhat I would like to have is every git tree in the same directory where\nI put my code (not necessary a super project tree).\n\nlike this :\n\nAnything/library_1\nAnything/library_2\nAnything/library_3\nAnything/library_4\nAnything/project_1 with a git submodule add ../library_1 ../library_2\nAnything/project_2 with a git submodule add ../library_1 ../library_3\nAnything/project_3 with a git submodule add ../library_2 ../library_4\n ../project_1\nAnything/project_4 with a git submodule add ../library_4 ../project_1\n ../project_2 ../project_3\n\nBut when I do this I receive a\n\"fatal: '../library_1' is outside repository\"\n\nThis is due to the fact that 'git add submodule' use the tests of\n'git add' which prevent creating files outside of the working tree for\nobvious security reasons.\n\nBut in my point of view the meaning of a submodule should be more like a\nsymlink on a repository than a sub tree.\nAnd symlink does not seams to be prohibited even if they link to\nsomething outside of the repository.\n\nI have tried a work around by doing :\n\"git submodule add library_1 library_2\" in project 1\nand then replacing library_1 and library_2 by symlinks to\n../library_1 and ../library_2\nbut git immediately track the symlink itself and not what is pointed to.\nAnd even if it had worked, this type of work around is not clean.\n\nI have think about removing the test in setup.c in case of adding a\nsubmodule. But I am not deeply involved in git source code then I am not\nsure of the possibles side effects of this modification.\n\nAs well may be there is an other solution that I still haven not think\nabout.\n\n\tHenri GEIST\n"},{"id":"170577","messageId":"7vvcvrxlol.fsf@alter.siamese.dyndns.org","threadId":"27708","inReplyTo":"1309180056.2497.220.camel@Naugrim.eriador.com","subject":"Re: tracking submodules out of main directory.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-06-27T16:51:06Z","receivedAt":"2011-06-27T16:51:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"henri GEIST writes:\n\n> We can obviously solve this by doing trees of submodules just reflecting\n> the trees of dependency but it create somme problems.\n>\n> 1. In project 4 I have 2 times project 1 and 3 times libraries 1 and 2\n> And 2 times library 4.\n> 2. It is a wast of space.\n> 3. Different version of the same libraries or projects could be used.\n> 4. when linking object, multiples objects will export the same symbols\n\nAll of the above are something your build procedure needs to solve\nregardless, even if you are not using git submodules (or even if you are\nnot using any SCM, for that matter). If you want to (and you do want to)\navoid duplication, version drift and associated issues of use of the\ncommon library 1 across project 1 and project 2, you would organize your\nsource tree so that both of your (sub)projects to use the library code\nfrom a common location.\n\nOne possible working tree organization may look like this:\n\n\t-+- lib1\n +- project1/Makefile -- refers to ../lib1\n +- project2/Makefile -- refers to ../lib1\n\nThe top-level superproject (what you called \"Anything\") binds project1,\nproject2 and lib1 as its submodules, and it can say where you want your\nusers to fetch these submodules in its .gitmodules, and at what version\nlib1 (and projects) to use in its tree objects as gitlinks.\n\nPeople who are _only_ interested in project1 can still clone that\ntop-level superproject, and \"submodule init\" only lib1 and project1,\nwithout running \"submodule init\" on project2.\n\nAn interesting point your situation raises is that there is no direct way\nto express module dependencies in .gitmodules file right now, I think.\nIdeally you would want \"submodule init project1\" to infer automatically\nthat project1 needs lib1 and run \"submodule init lib1\" for you. My gut\nfeeling is that it belongs to .gitmodules of the superproject.\n"},{"id":"170582","messageId":"4E08C89E.5020109@web.de","threadId":"27708","inReplyTo":"7vvcvrxlol.fsf@alter.siamese.dyndns.org","subject":"Re: tracking submodules out of main directory.","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-06-27T18:14:54Z","receivedAt":"2011-06-27T18:14:54Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 27.06.2011 18:51, schrieb Junio C Hamano:\n> One possible working tree organization may look like this:\n> \n> \t-+- lib1\n> +- project1/Makefile -- refers to ../lib1\n> +- project2/Makefile -- refers to ../lib1\n\nThis is what we do at work and it works really well for us. The\npossible downside (that you can't tie project1 and project2 to a\nspecific version of lib1 in their own repo) is not a real problem\nin our experience, as the superproject ties the correct combination\ntogether.\n\n> An interesting point your situation raises is that there is no direct way\n> to express module dependencies in .gitmodules file right now, I think.\n> Ideally you would want \"submodule init project1\" to infer automatically\n> that project1 needs lib1 and run \"submodule init lib1\" for you. My gut\n> feeling is that it belongs to .gitmodules of the superproject\n\nThat is where this is handled now, but having a submodule refer to a\nsubmodule outside of it as a dependency is an interesting thought. But\nas that only matters at the moment you add project1 (and it won't compile\nbecause ../lib1 is missing, which can easily handled by: \"oh, then I have\nto add lib1 as a submodule to the superproject too\"), I'm not sure that\nwould be a huge improvement over just having a sane convention of where\nto get lib1 from.\n"},{"id":"170584","messageId":"1309200051.2497.288.camel@Naugrim.eriador.com","threadId":"27708","inReplyTo":"7vvcvrxlol.fsf@alter.siamese.dyndns.org","subject":"Re: tracking submodules out of main directory.","fromName":"henri GEIST","fromEmail":"henri.geist@flying-robots.com","sentAt":"2011-06-27T18:40:51Z","receivedAt":"2011-06-27T18:40:51Z","isPatch":false,"sender":{"key":"henri.geist@flying-robots.com","avatar":null},"body":"First of all thank you for your answer.\n\nLe lundi 27 juin 2011 à 09:51 -0700, Junio C Hamano a écrit :\n> henri GEIST writes:\n> \n>> We can obviously solve this by doing trees of submodules just reflecting\n>> the trees of dependency but it create somme problems.\n>>\n>> 1. In project 4 I have 2 times project 1 and 3 times libraries 1 and 2\n>> And 2 times library 4.\n>> 2. It is a wast of space.\n>> 3. Different version of the same libraries or projects could be used.\n>> 4. when linking object, multiples objects will export the same symbols\n> \n> All of the above are something your build procedure needs to solve\n> regardless, even if you are not using git submodules (or even if you are\n> not using any SCM, for that matter). If you want to (and you do want to)\n> avoid duplication, version drift and associated issues of use of the\n> common library 1 across project 1 and project 2, you would organize your\n> source tree so that both of your (sub)projects to use the library code\n> from a common location.\n> \n> One possible working tree organization may look like this:\n> \n> \t-+- lib1\n> +- project1/Makefile -- refers to ../lib1\n> +- project2/Makefile -- refers to ../lib1\n> \n\nI agree on this point.\nAnd that is just what I do and mean by :\n\n>> Anything/library_1\n>> Anything/library_2\n>> Anything/library_3\n>> Anything/library_4\n>> Anything/project_1 with a git submodule add ../library_1 ../library_2\n>> Anything/project_2 with a git submodule add ../library_1 ../library_3\n>> Anything/project_3 with a git submodule add ../library_2 ../library_4\n>> ../project_1\n>> Anything/project_4 with a git submodule add ../library_4 ../project_1\n>> ../project_2 ../project_3\n\nI would like git to do just the same thing that do my Makefile.\n\n> The top-level superproject (what you called \"Anything\") binds project1,\n> project2 and lib1 as its submodules, and it can say where you want your\n> users to fetch these submodules in its .gitmodules, and at what version\n> lib1 (and projects) to use in its tree objects as gitlinks.\n> \n\nUntil now I did not thought about making \"Anything\" a git repository.\nIt was just a simple directory containing all my projects.\nAnd project_4 was not a submodule of anything.\n\nMay be I need to think more about it.\n\nBut actually it is just pushing the problem one rank more by making\n\"Anything\" a kind of project_5 which contain submodules in sub\ndirectories and will rase the same problem the day project_6 will need\nproject_5.\nAnd it does not solve the problem of making project_1 knowing is need to\nbe linked to library_1 in version \"abcd1234...\"\n\n> People who are _only_ interested in project1 can still clone that\n> top-level superproject, and \"submodule init\" only lib1 and project1,\n> without running \"submodule init\" on project2.\n> \n\nI agree on this point.\n\n> An interesting point your situation raises is that there is no direct way\n> to express module dependencies in .gitmodules file right now, I think.\n\nAnd that is the real problem.\nIt could be done for submodule inside of the project main directory.\nBut not for modules outside of it.\n\n> Ideally you would want \"submodule init project1\" to infer automatically\n> that project1 needs lib1 and run \"submodule init lib1\" for you. My gut\n> feeling is that it belongs to .gitmodules of the superproject.\n> \n\nI do not really care about project_1 doing the submodule init.\nI can easily do it by myself.\nAnd in fact I use to write the libraries before the project using them.\nthen there git repositories already exist\n\nwhat I really need is to do :\n\ncd project_1\ngit add ../library_1\n\nthen in case of modification in library_1\n\nA git status in project_1 directory will say me :\n\nmodified: ../library_1 (modified content)\nor\nmodified: ../library_1 (new commits)\nor even\nmodified: ../library_1 (new commits, modified content)\n\nJust like it do for submodules with out \"../\" in the path.\n\nAnd I really think the metadata to do so should be stored in project_1\nsince it is him which depend on library_1 version \"abcd1234...\" and this\ninformation need to be self contained.\nMay be in project_1/.git or project_1/.gitmodules\n\nI do not see the point of having a third party project \"Anything\" Just\nto say to project_1 hey you need library_1.\nIf it need it, it should already know it.\n\n\n\tHenri GEIST\n"},{"id":"170586","messageId":"1309200722.2497.294.camel@Naugrim.eriador.com","threadId":"27708","inReplyTo":"4E08C89E.5020109@web.de","subject":"Re: tracking submodules out of main directory.","fromName":"henri GEIST","fromEmail":"henri.geist@flying-robots.com","sentAt":"2011-06-27T18:52:02Z","receivedAt":"2011-06-27T18:52:02Z","isPatch":false,"sender":{"key":"henri.geist@flying-robots.com","avatar":null},"body":"Le lundi 27 juin 2011 à 20:14 +0200, Jens Lehmann a écrit :\n> Am 27.06.2011 18:51, schrieb Junio C Hamano:\n> > One possible working tree organization may look like this:\n> > \n> > \t-+- lib1\n> > +- project1/Makefile -- refers to ../lib1\n> > +- project2/Makefile -- refers to ../lib1\n> \n> This is what we do at work and it works really well for us. The\n> possible downside (that you can't tie project1 and project2 to a\n> specific version of lib1 in their own repo) is not a real problem\n> in our experience, as the superproject ties the correct combination\n> together.\n> \n\nThat is a good starting point.\nI have used this method for some little projects and it work great.\n\nBut I had never find a mean to handle the case of project1 depending on\nboth lib1 and lib2.\n\n\tHenri GEIST\n"},{"id":"170587","messageId":"4E08D279.7060202@web.de","threadId":"27708","inReplyTo":"1309200722.2497.294.camel@Naugrim.eriador.com","subject":"Re: tracking submodules out of main directory.","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-06-27T18:56:57Z","receivedAt":"2011-06-27T18:56:57Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 27.06.2011 20:52, schrieb henri GEIST:\n> Le lundi 27 juin 2011 à 20:14 +0200, Jens Lehmann a écrit :\n>> Am 27.06.2011 18:51, schrieb Junio C Hamano:\n>>> One possible working tree organization may look like this:\n>>>\n>>> \t-+- lib1\n>>> +- project1/Makefile -- refers to ../lib1\n>>> +- project2/Makefile -- refers to ../lib1\n>>\n>> This is what we do at work and it works really well for us. The\n>> possible downside (that you can't tie project1 and project2 to a\n>> specific version of lib1 in their own repo) is not a real problem\n>> in our experience, as the superproject ties the correct combination\n>> together.\n>>\n> \n> That is a good starting point.\n> I have used this method for some little projects and it work great.\n> \n> But I had never find a mean to handle the case of project1 depending on\n> both lib1 and lib2.\n\nHmm, but isn't that covered by having lib1, lib2 & project1 right next\nto each other in your superproject?\n"},{"id":"170588","messageId":"4E08D3B9.401@web.de","threadId":"27708","inReplyTo":"1309200051.2497.288.camel@Naugrim.eriador.com","subject":"Re: tracking submodules out of main directory.","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-06-27T19:02:17Z","receivedAt":"2011-06-27T19:02:17Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 27.06.2011 20:40, schrieb henri GEIST:\n> what I really need is to do :\n> \n> cd project_1\n> git add ../library_1\n> \n> then in case of modification in library_1\n> \n> A git status in project_1 directory will say me :\n> \n> modified: ../library_1 (modified content)\n> or\n> modified: ../library_1 (new commits)\n> or even\n> modified: ../library_1 (new commits, modified content)\n> \n> Just like it do for submodules with out \"../\" in the path.\n> \n> And I really think the metadata to do so should be stored in project_1\n> since it is him which depend on library_1 version \"abcd1234...\" and this\n> information need to be self contained.\n> May be in project_1/.git or project_1/.gitmodules\n> \n> I do not see the point of having a third party project \"Anything\" Just\n> to say to project_1 hey you need library_1.\n> If it need it, it should already know it.\n\nThe point is it avoids ambiguity and cross-dependencies. If you have\nproject_1 requesting the version \"123456\" of library_1 and project_2\nwants \"abcdef\", you'll always have one project disagreeing (= being\ndirty). But \"abcdef\" might be a direct descendant of \"123456\" and is\njust fixing a bug that affects only project_2. So it would be ok for\nboth to have \"abcdef\", but you'll have to add an extra commit to\nproject_1 saying \"updating library_1 because of bug in project_2\" to\nmake it clean again. That would make the projects not so modular and\nindependent anymore and won't scale well.\n\nIf the superproject records these dependencies you just update\nlibrary_1, run all tests (including those in project_1 & project_2)\nand commit that in the superproject.\n"},{"id":"170589","messageId":"7vvcvrw0vn.fsf@alter.siamese.dyndns.org","threadId":"27708","inReplyTo":"4E08C89E.5020109@web.de","subject":"Re: tracking submodules out of main directory.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-06-27T19:05:48Z","receivedAt":"2011-06-27T19:05:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jens Lehmann writes:\n\n> Am 27.06.2011 18:51, schrieb Junio C Hamano:\n>> One possible working tree organization may look like this:\n>> \n>> \t-+- lib1\n>> +- project1/Makefile -- refers to ../lib1\n>> +- project2/Makefile -- refers to ../lib1\n> ...\n>> An interesting point your situation raises is that there is no direct way\n>> to express module dependencies in .gitmodules file right now, I think.\n>> Ideally you would want \"submodule init project1\" to infer automatically\n>> that project1 needs lib1 and run \"submodule init lib1\" for you. My gut\n>> feeling is that it belongs to .gitmodules of the superproject\n>\n> That is where this is handled now, but having a submodule refer to a\n> submodule outside of it as a dependency is an interesting thought. But\n> as that only matters at the moment you add project1 (and it won't compile\n> because ../lib1 is missing, which can easily handled by: \"oh, then I have\n> to add lib1 as a submodule to the superproject too\"), ...\n\nThat is what I called \"there is no direct way\". Wouldn't it be nicer if\nthe .gitmodules file in the superproject said something like\n\n\t[module \"project one\"]\n\t\tpath = project1\n \turl = ...\n depends = lib1\n\t[module \"lib1\"]\n \tpath = lib1\n url = ...\n\nand then \"git submodule init project1\" run by the end user implied running\nalso \"git submodule init lib1\"?\n"},{"id":"170592","messageId":"4E08DCB1.3080503@web.de","threadId":"27708","inReplyTo":"7vvcvrw0vn.fsf@alter.siamese.dyndns.org","subject":"Re: tracking submodules out of main directory.","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-06-27T19:40:33Z","receivedAt":"2011-06-27T19:40:33Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 27.06.2011 21:05, schrieb Junio C Hamano:\n> Jens Lehmann writes:\n> \n>> Am 27.06.2011 18:51, schrieb Junio C Hamano:\n>>> One possible working tree organization may look like this:\n>>>\n>>> \t-+- lib1\n>>> +- project1/Makefile -- refers to ../lib1\n>>> +- project2/Makefile -- refers to ../lib1\n>> ...\n>>> An interesting point your situation raises is that there is no direct way\n>>> to express module dependencies in .gitmodules file right now, I think.\n>>> Ideally you would want \"submodule init project1\" to infer automatically\n>>> that project1 needs lib1 and run \"submodule init lib1\" for you. My gut\n>>> feeling is that it belongs to .gitmodules of the superproject\n>>\n>> That is where this is handled now, but having a submodule refer to a\n>> submodule outside of it as a dependency is an interesting thought. But\n>> as that only matters at the moment you add project1 (and it won't compile\n>> because ../lib1 is missing, which can easily handled by: \"oh, then I have\n>> to add lib1 as a submodule to the superproject too\"), ...\n> \n> That is what I called \"there is no direct way\". Wouldn't it be nicer if\n> the .gitmodules file in the superproject said something like\n> \n> \t[module \"project one\"]\n> \t\tpath = project1\n> \turl = ...\n> depends = lib1\n> \t[module \"lib1\"]\n> \tpath = lib1\n> url = ...\n> \n> and then \"git submodule init project1\" run by the end user implied running\n> also \"git submodule init lib1\"?\n\nAnd if lib1 happens to have another dependency, that will be initialized\ntoo? That would make life much easier for users who only want certain\nsubmodules populated to work on, as they won't have to chase compile\nerrors anymore until they found all necessary submodules ... very nice.\n"},{"id":"170594","messageId":"1309209488.2497.363.camel@Naugrim.eriador.com","threadId":"27708","inReplyTo":"4E08D279.7060202@web.de","subject":"Re: tracking submodules out of main directory.","fromName":"henri GEIST","fromEmail":"henri.geist@flying-robots.com","sentAt":"2011-06-27T21:18:08Z","receivedAt":"2011-06-27T21:18:08Z","isPatch":false,"sender":{"key":"henri.geist@flying-robots.com","avatar":null},"body":"Le lundi 27 juin 2011 à 20:56 +0200, Jens Lehmann a écrit :\n> Am 27.06.2011 20:52, schrieb henri GEIST:\n> > Le lundi 27 juin 2011 à 20:14 +0200, Jens Lehmann a écrit :\n> >> Am 27.06.2011 18:51, schrieb Junio C Hamano:\n> >>> One possible working tree organization may look like this:\n> >>>\n> >>> \t-+- lib1\n> >>> +- project1/Makefile -- refers to ../lib1\n> >>> +- project2/Makefile -- refers to ../lib1\n> >>\n> >> This is what we do at work and it works really well for us. The\n> >> possible downside (that you can't tie project1 and project2 to a\n> >> specific version of lib1 in their own repo) is not a real problem\n> >> in our experience, as the superproject ties the correct combination\n> >> together.\n> >>\n> > \n> > That is a good starting point.\n> > I have used this method for some little projects and it work great.\n> > \n> > But I had never find a mean to handle the case of project1 depending on\n> > both lib1 and lib2.\n> \n> Hmm, but isn't that covered by having lib1, lib2 & project1 right next\n> to each other in your superproject?\n> \n\nSorry I havent read well your schema. I have thought that you reversed\ndependency and put project1 and project2 inside libs1.\n\n\tHenri GEIST\n"},{"id":"170596","messageId":"1309211154.2497.391.camel@Naugrim.eriador.com","threadId":"27708","inReplyTo":"4E08D3B9.401@web.de","subject":"Re: tracking submodules out of main directory.","fromName":"henri GEIST","fromEmail":"henri.geist@flying-robots.com","sentAt":"2011-06-27T21:45:54Z","receivedAt":"2011-06-27T21:45:54Z","isPatch":false,"sender":{"key":"henri.geist@flying-robots.com","avatar":null},"body":"Le lundi 27 juin 2011 à 21:02 +0200, Jens Lehmann a écrit :\n> Am 27.06.2011 20:40, schrieb henri GEIST:\n> > what I really need is to do :\n> > \n> > cd project_1\n> > git add ../library_1\n> > \n> > then in case of modification in library_1\n> > \n> > A git status in project_1 directory will say me :\n> > \n> > modified: ../library_1 (modified content)\n> > or\n> > modified: ../library_1 (new commits)\n> > or even\n> > modified: ../library_1 (new commits, modified content)\n> > \n> > Just like it do for submodules with out \"../\" in the path.\n> > \n> > And I really think the metadata to do so should be stored in project_1\n> > since it is him which depend on library_1 version \"abcd1234...\" and this\n> > information need to be self contained.\n> > May be in project_1/.git or project_1/.gitmodules\n> > \n> > I do not see the point of having a third party project \"Anything\" Just\n> > to say to project_1 hey you need library_1.\n> > If it need it, it should already know it.\n> \n> The point is it avoids ambiguity and cross-dependencies. If you have\n> project_1 requesting the version \"123456\" of library_1 and project_2\n> wants \"abcdef\", you'll always have one project disagreeing (= being\n> dirty).\n\nYes that is exactly what I want.\n\n> But \"abcdef\" might be a direct descendant of \"123456\" and is\n> just fixing a bug that affects only project_2.\n\nYes but you can not make a rule of this the difference can have any\nreason.\nAnd mare often the bug has a chance to affect both project.\nIn any case both will be improved with a version more correct.\n\n> So it would be ok for\n> both to have \"abcdef\", but you'll have to add an extra commit to\n> project_1 saying \"updating library_1 because of bug in project_2\" to\n> make it clean again.\n\nYes that is also exactly what I want.\n\n> That would make the projects not so modular and\n> independent anymore and won't scale well.\n> \n\nIt is sufficiently independent for me.\n - If some one pull only project1 from me he will have a consistent\n library_1 at \"123456\"\n\n - If some one pull only project2 from me he will have a consistent\n library_1 at \"abcdef\"\n\n - The conflicting version dependency is only in my working directory\n to be solved. And in my work flow updating project_1 to reflect the\n correction in library_1 is the thing to do.\n\n - If some one decide tu pull from me both project_1 and project_2 in\n the same working tree he will effectively inherit my conflict.\n But that also mean he is working on both project and decide to take\n account of the relation between them like me.\n Then the first one who upgrade project1 will be pulled by the other\n one.\n\n - In any case if you have no time to update a project an need to\n immediately work on it you always can :\n\n - Go in the library one directory and checkout the right version\n for the project.\n\n - Or clone project alone with its libraries in a completely\n separate directory.\n\n> If the superproject records these dependencies you just update\n> library_1, run all tests (including those in project_1 & project_2)\n> and commit that in the superproject.\n> \nIn this case you could not commit anything until every thing has been\ndone without breaking something.\n\nWhen committing library_1 to \"abcdef\" nothing wrong happen in both case\nall project still point to \"123456\"\n\nwhen committing project_2 it will need to point to \"abcdef\" but in your\nwork flow the super project still say him it point to \"123456\" and\nproject_2 is broken.\n\nIf you immediately commit the superproject to repair project_2 you will\nbrake project_1 until it is also upgraded and superproject is reupgraded\nto reflect it.\n\n\n\nIn my work flow when committing project it will immediately point to\n\"abcdef\" and not been broken.\n\nproject_1 still point to \"123456\" and is still not broken\n\nsuperproject which is not needed still point on all old versions and is\nnot broken.\n\nOn commit of project1 it will immediately point to \"abcdef\" an is not\nbroken\n\nsuperproject will till point on all old versions and is not broken.\n\nOn commit of super project if we have one every thing is up to date.\n\n\tHenri GEIST\n"},{"id":"170597","messageId":"1309211460.2497.395.camel@Naugrim.eriador.com","threadId":"27708","inReplyTo":"7vvcvrw0vn.fsf@alter.siamese.dyndns.org","subject":"Re: tracking submodules out of main directory.","fromName":"henri GEIST","fromEmail":"henri.geist@flying-robots.com","sentAt":"2011-06-27T21:51:00Z","receivedAt":"2011-06-27T21:51:00Z","isPatch":false,"sender":{"key":"henri.geist@flying-robots.com","avatar":null},"body":"Le lundi 27 juin 2011 à 12:05 -0700, Junio C Hamano a écrit :\n> Jens Lehmann writes:\n> \n> > Am 27.06.2011 18:51, schrieb Junio C Hamano:\n> >> One possible working tree organization may look like this:\n> >> \n> >> \t-+- lib1\n> >> +- project1/Makefile -- refers to ../lib1\n> >> +- project2/Makefile -- refers to ../lib1\n> > ...\n> >> An interesting point your situation raises is that there is no direct way\n> >> to express module dependencies in .gitmodules file right now, I think.\n> >> Ideally you would want \"submodule init project1\" to infer automatically\n> >> that project1 needs lib1 and run \"submodule init lib1\" for you. My gut\n> >> feeling is that it belongs to .gitmodules of the superproject\n> >\n> > That is where this is handled now, but having a submodule refer to a\n> > submodule outside of it as a dependency is an interesting thought. But\n> > as that only matters at the moment you add project1 (and it won't compile\n> > because ../lib1 is missing, which can easily handled by: \"oh, then I have\n> > to add lib1 as a submodule to the superproject too\"), ...\n> \n> That is what I called \"there is no direct way\". Wouldn't it be nicer if\n> the .gitmodules file in the superproject said something like\n> \n> \t[module \"project one\"]\n> \t\tpath = project1\n> \turl = ...\n> depends = lib1\n> \t[module \"lib1\"]\n> \tpath = lib1\n> url = ...\n> \n> and then \"git submodule init project1\" run by the end user implied running\n> also \"git submodule init lib1\"?\n> \n> \n\nThis could be a way if .gitmodules can contain something like\n\n\t[module \"project one\"]\n\t\tpath = project1\n \turl = ...\n depends = lib1\t\"123456\"\n\t[module \"project two\"]\n\t\tpath = project2\n \turl = ...\n depends = lib1\t\"abcdef\"\n\t[module \"lib1\"]\n \tpath = lib1\n url = ...\n\n\n\nHenri GEIST\n"},{"id":"170598","messageId":"1309211840.2497.401.camel@Naugrim.eriador.com","threadId":"27708","inReplyTo":"4E08DCB1.3080503@web.de","subject":"Re: tracking submodules out of main directory.","fromName":"henri GEIST","fromEmail":"henri.geist@flying-robots.com","sentAt":"2011-06-27T21:57:20Z","receivedAt":"2011-06-27T21:57:20Z","isPatch":false,"sender":{"key":"henri.geist@flying-robots.com","avatar":null},"body":"Le lundi 27 juin 2011 à 21:40 +0200, Jens Lehmann a écrit :\n> Am 27.06.2011 21:05, schrieb Junio C Hamano:\n> > Jens Lehmann writes:\n> > \n> >> Am 27.06.2011 18:51, schrieb Junio C Hamano:\n> >>> One possible working tree organization may look like this:\n> >>>\n> >>> \t-+- lib1\n> >>> +- project1/Makefile -- refers to ../lib1\n> >>> +- project2/Makefile -- refers to ../lib1\n> >> ...\n> >>> An interesting point your situation raises is that there is no direct way\n> >>> to express module dependencies in .gitmodules file right now, I think.\n> >>> Ideally you would want \"submodule init project1\" to infer automatically\n> >>> that project1 needs lib1 and run \"submodule init lib1\" for you. My gut\n> >>> feeling is that it belongs to .gitmodules of the superproject\n> >>\n> >> That is where this is handled now, but having a submodule refer to a\n> >> submodule outside of it as a dependency is an interesting thought. But\n> >> as that only matters at the moment you add project1 (and it won't compile\n> >> because ../lib1 is missing, which can easily handled by: \"oh, then I have\n> >> to add lib1 as a submodule to the superproject too\"), ...\n> > \n> > That is what I called \"there is no direct way\". Wouldn't it be nicer if\n> > the .gitmodules file in the superproject said something like\n> > \n> > \t[module \"project one\"]\n> > \t\tpath = project1\n> > \turl = ...\n> > depends = lib1\n> > \t[module \"lib1\"]\n> > \tpath = lib1\n> > url = ...\n> > \n> > and then \"git submodule init project1\" run by the end user implied running\n> > also \"git submodule init lib1\"?\n> \n> And if lib1 happens to have another dependency, that will be initialized\n> too? That would make life much easier for users who only want certain\n> submodules populated to work on, as they won't have to chase compile\n> errors anymore until they found all necessary submodules ... very nice.\n> \n\nThat is right.\nBut could also be done with the .gitmodules in project1 containing\n\n\t[module \"lib1\"]\n \tpath = ../lib1\n url = ...\n\nand making implicite if the module is describe in .gitmodules that\nmean ./ depend on it.\n\n\tHenri GEIST\n"},{"id":"170609","messageId":"4E0980D5.8040004@web.de","threadId":"27708","inReplyTo":"1309211460.2497.395.camel@Naugrim.eriador.com","subject":"Re: tracking submodules out of main directory.","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-06-28T07:20:53Z","receivedAt":"2011-06-28T07:20:53Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 27.06.2011 23:51, schrieb henri GEIST:\n> Le lundi 27 juin 2011 à 12:05 -0700, Junio C Hamano a écrit :\n>> Jens Lehmann writes:\n>>\n>>> Am 27.06.2011 18:51, schrieb Junio C Hamano:\n>>>> One possible working tree organization may look like this:\n>>>>\n>>>> \t-+- lib1\n>>>> +- project1/Makefile -- refers to ../lib1\n>>>> +- project2/Makefile -- refers to ../lib1\n>>> ...\n>>>> An interesting point your situation raises is that there is no direct way\n>>>> to express module dependencies in .gitmodules file right now, I think.\n>>>> Ideally you would want \"submodule init project1\" to infer automatically\n>>>> that project1 needs lib1 and run \"submodule init lib1\" for you. My gut\n>>>> feeling is that it belongs to .gitmodules of the superproject\n>>>\n>>> That is where this is handled now, but having a submodule refer to a\n>>> submodule outside of it as a dependency is an interesting thought. But\n>>> as that only matters at the moment you add project1 (and it won't compile\n>>> because ../lib1 is missing, which can easily handled by: \"oh, then I have\n>>> to add lib1 as a submodule to the superproject too\"), ...\n>>\n>> That is what I called \"there is no direct way\". Wouldn't it be nicer if\n>> the .gitmodules file in the superproject said something like\n>>\n>> \t[module \"project one\"]\n>> \t\tpath = project1\n>> \turl = ...\n>> depends = lib1\n>> \t[module \"lib1\"]\n>> \tpath = lib1\n>> url = ...\n>>\n>> and then \"git submodule init project1\" run by the end user implied running\n>> also \"git submodule init lib1\"?\n>>\n>>\n> \n> This could be a way if .gitmodules can contain something like\n> \n> \t[module \"project one\"]\n> \t\tpath = project1\n> \turl = ...\n> depends = lib1\t\"123456\"\n> \t[module \"project two\"]\n> \t\tpath = project2\n> \turl = ...\n> depends = lib1\t\"abcdef\"\n> \t[module \"lib1\"]\n> \tpath = lib1\n> url = ...\n\nBut there is no need for that as \"123456\" and \"abcdef\" are already present\nas the sha1 values for the gitlinks \"lib1\" and \"lib2\".\n"},{"id":"170610","messageId":"4E0981F0.6040507@web.de","threadId":"27708","inReplyTo":"1309211840.2497.401.camel@Naugrim.eriador.com","subject":"Re: tracking submodules out of main directory.","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-06-28T07:25:36Z","receivedAt":"2011-06-28T07:25:36Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 27.06.2011 23:57, schrieb henri GEIST:\n> Le lundi 27 juin 2011 à 21:40 +0200, Jens Lehmann a écrit :\n>> Am 27.06.2011 21:05, schrieb Junio C Hamano:\n>>> Jens Lehmann writes:\n>>>\n>>>> Am 27.06.2011 18:51, schrieb Junio C Hamano:\n>>>>> One possible working tree organization may look like this:\n>>>>>\n>>>>> \t-+- lib1\n>>>>> +- project1/Makefile -- refers to ../lib1\n>>>>> +- project2/Makefile -- refers to ../lib1\n>>>> ...\n>>>>> An interesting point your situation raises is that there is no direct way\n>>>>> to express module dependencies in .gitmodules file right now, I think.\n>>>>> Ideally you would want \"submodule init project1\" to infer automatically\n>>>>> that project1 needs lib1 and run \"submodule init lib1\" for you. My gut\n>>>>> feeling is that it belongs to .gitmodules of the superproject\n>>>>\n>>>> That is where this is handled now, but having a submodule refer to a\n>>>> submodule outside of it as a dependency is an interesting thought. But\n>>>> as that only matters at the moment you add project1 (and it won't compile\n>>>> because ../lib1 is missing, which can easily handled by: \"oh, then I have\n>>>> to add lib1 as a submodule to the superproject too\"), ...\n>>>\n>>> That is what I called \"there is no direct way\". Wouldn't it be nicer if\n>>> the .gitmodules file in the superproject said something like\n>>>\n>>> \t[module \"project one\"]\n>>> \t\tpath = project1\n>>> \turl = ...\n>>> depends = lib1\n>>> \t[module \"lib1\"]\n>>> \tpath = lib1\n>>> url = ...\n>>>\n>>> and then \"git submodule init project1\" run by the end user implied running\n>>> also \"git submodule init lib1\"?\n>>\n>> And if lib1 happens to have another dependency, that will be initialized\n>> too? That would make life much easier for users who only want certain\n>> submodules populated to work on, as they won't have to chase compile\n>> errors anymore until they found all necessary submodules ... very nice.\n>>\n> \n> That is right.\n> But could also be done with the .gitmodules in project1 containing\n> \n> \t[module \"lib1\"]\n> \tpath = ../lib1\n> url = ...\n> \n> and making implicite if the module is describe in .gitmodules that\n> mean ./ depend on it.\n\nBut that would be much more complicated than just recording that in the\nsuperproject's .gitmodules. In a Git repo everything lives in a directory\ntree, if you want to reference something outside of that tree things will\nget very complicated ... and I'm not sure the benefit is worth the hassle.\n"},{"id":"170611","messageId":"4E0984D0.80506@web.de","threadId":"27708","inReplyTo":"4E0980D5.8040004@web.de","subject":"Re: tracking submodules out of main directory.","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-06-28T07:37:52Z","receivedAt":"2011-06-28T07:37:52Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 28.06.2011 09:20, schrieb Jens Lehmann:\n>> This could be a way if .gitmodules can contain something like\n>>\n>> \t[module \"project one\"]\n>> \t\tpath = project1\n>> \turl = ...\n>> depends = lib1\t\"123456\"\n>> \t[module \"project two\"]\n>> \t\tpath = project2\n>> \turl = ...\n>> depends = lib1\t\"abcdef\"\n>> \t[module \"lib1\"]\n>> \tpath = lib1\n>> url = ...\n> \n> But there is no need for that as \"123456\" and \"abcdef\" are already present\n> as the sha1 values for the gitlinks \"lib1\" and \"lib2\".\n\n... but of course you would have to decide which sha1 is the right one for\nlib1, while your proposal offers two contradicting sha1s (note to self: must\ndrink coffee *before* answering emails in the morning ;-)\n"},{"id":"170613","messageId":"BANLkTimsfR4LqDAci0Vr+m9uUE_W-7OSAw@mail.gmail.com","threadId":"27708","inReplyTo":"7vvcvrw0vn.fsf@alter.siamese.dyndns.org","subject":"Re: tracking submodules out of main directory.","fromName":"Alexei Sholik","fromEmail":"alcosholik@gmail.com","sentAt":"2011-06-28T10:05:10Z","receivedAt":"2011-06-28T10:05:10Z","isPatch":false,"sender":{"key":"alcosholik@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207748?v=4"},"body":"On 27 June 2011 22:05, Junio C Hamano wrote:\n> That is what I called \"there is no direct way\". Wouldn't it be nicer if\n> the .gitmodules file in the superproject said something like\n>\n>        [module \"project one\"]\n>                path = project1\n>                url = ...\n>                depends = lib1\n>        [module \"lib1\"]\n>                path = lib1\n>                url = ...\n>\n> and then \"git submodule init project1\" run by the end user implied running\n> also \"git submodule init lib1\"?\n\nThis is a very nice idea. In my workflow, I find it that I more often\nneed to clone a repo _including_ its submodules, because the top-level\nproject won't compile without them. If we had a way to specify\ndependencies on submodules, `git pull` could automatically init and\nupdate them.\n\nIf a user really wants to clone only the top-level repo without\nsubmodules, git could provide him with an option for `git pull` (like\n`git pull --shallow`) to do just that. I think this second scenario is\nless common, so it is more reasonable to have a '--shallow' option for\nit, instead of '--recursive' counterpart.\n\n-- \nBest regards,\nAlexei Sholik\n"},{"id":"170621","messageId":"1309261962.2497.413.camel@Naugrim.eriador.com","threadId":"27708","inReplyTo":"4E0980D5.8040004@web.de","subject":"Re: tracking submodules out of main directory.","fromName":"henri GEIST","fromEmail":"henri.geist@flying-robots.com","sentAt":"2011-06-28T11:52:42Z","receivedAt":"2011-06-28T11:52:42Z","isPatch":false,"sender":{"key":"henri.geist@flying-robots.com","avatar":null},"body":"Le mardi 28 juin 2011 à 09:20 +0200, Jens Lehmann a écrit :\n> Am 27.06.2011 23:51, schrieb henri GEIST:\n> > Le lundi 27 juin 2011 à 12:05 -0700, Junio C Hamano a écrit :\n> >> Jens Lehmann writes:\n> >>\n> >>> Am 27.06.2011 18:51, schrieb Junio C Hamano:\n> >>>> One possible working tree organization may look like this:\n> >>>>\n> >>>> \t-+- lib1\n> >>>> +- project1/Makefile -- refers to ../lib1\n> >>>> +- project2/Makefile -- refers to ../lib1\n> >>> ...\n> >>>> An interesting point your situation raises is that there is no direct way\n> >>>> to express module dependencies in .gitmodules file right now, I think.\n> >>>> Ideally you would want \"submodule init project1\" to infer automatically\n> >>>> that project1 needs lib1 and run \"submodule init lib1\" for you. My gut\n> >>>> feeling is that it belongs to .gitmodules of the superproject\n> >>>\n> >>> That is where this is handled now, but having a submodule refer to a\n> >>> submodule outside of it as a dependency is an interesting thought. But\n> >>> as that only matters at the moment you add project1 (and it won't compile\n> >>> because ../lib1 is missing, which can easily handled by: \"oh, then I have\n> >>> to add lib1 as a submodule to the superproject too\"), ...\n> >>\n> >> That is what I called \"there is no direct way\". Wouldn't it be nicer if\n> >> the .gitmodules file in the superproject said something like\n> >>\n> >> \t[module \"project one\"]\n> >> \t\tpath = project1\n> >> \turl = ...\n> >> depends = lib1\n> >> \t[module \"lib1\"]\n> >> \tpath = lib1\n> >> url = ...\n> >>\n> >> and then \"git submodule init project1\" run by the end user implied running\n> >> also \"git submodule init lib1\"?\n> >>\n> >>\n> > \n> > This could be a way if .gitmodules can contain something like\n> > \n> > \t[module \"project one\"]\n> > \t\tpath = project1\n> > \turl = ...\n> > depends = lib1\t\"123456\"\n> > \t[module \"project two\"]\n> > \t\tpath = project2\n> > \turl = ...\n> > depends = lib1\t\"abcdef\"\n> > \t[module \"lib1\"]\n> > \tpath = lib1\n> > url = ...\n> \n> But there is no need for that as \"123456\" and \"abcdef\" are already present\n> as the sha1 values for the gitlinks \"lib1\" and \"lib2\".\n> \n\nFor what I understand of gitlinks reading the git source code it\neffectively seem to be the functionality I am looking for.\nIt seem to be the pointer to the version of the module stored in the\nindex. Am I right ?\n\nBut I dont see a way to put 2 gitlinks pointing on 2 version of the same\nsubmodule in the index of the superproject. And then specifying\ngitlink_1 represent lib1 \"123456\" the dependency of project_1 and\ngitlink_2 represent lib1 \"abcdef\" the dependency of project_2.\n\n\tHenri GEIST\n"},{"id":"170620","messageId":"1309262157.2497.416.camel@Naugrim.eriador.com","threadId":"27708","inReplyTo":"4E0981F0.6040507@web.de","subject":"Re: tracking submodules out of main directory.","fromName":"henri GEIST","fromEmail":"henri.geist@flying-robots.com","sentAt":"2011-06-28T11:55:57Z","receivedAt":"2011-06-28T11:55:57Z","isPatch":false,"sender":{"key":"henri.geist@flying-robots.com","avatar":null},"body":"\n> >>>\n> >>> That is what I called \"there is no direct way\". Wouldn't it be nicer if\n> >>> the .gitmodules file in the superproject said something like\n> >>>\n> >>> \t[module \"project one\"]\n> >>> \t\tpath = project1\n> >>> \turl = ...\n> >>> depends = lib1\n> >>> \t[module \"lib1\"]\n> >>> \tpath = lib1\n> >>> url = ...\n> >>>\n> >>> and then \"git submodule init project1\" run by the end user implied running\n> >>> also \"git submodule init lib1\"?\n> >>\n> >> And if lib1 happens to have another dependency, that will be initialized\n> >> too? That would make life much easier for users who only want certain\n> >> submodules populated to work on, as they won't have to chase compile\n> >> errors anymore until they found all necessary submodules ... very nice.\n> >>\n> > \n> > That is right.\n> > But could also be done with the .gitmodules in project1 containing\n> > \n> > \t[module \"lib1\"]\n> > \tpath = ../lib1\n> > url = ...\n> > \n> > and making implicite if the module is describe in .gitmodules that\n> > mean ./ depend on it.\n> \n> But that would be much more complicated than just recording that in the\n> superproject's .gitmodules. In a Git repo everything lives in a directory\n> tree, if you want to reference something outside of that tree things will\n> get very complicated ... and I'm not sure the benefit is worth the hassle.\n> \n\nI am actually working on the git source code to give it a try and see if\nI can managed to make a patch without breaking anything else.\n\n\tHenri GEIST\n"},{"id":"170632","messageId":"4E0A08AE.8090407@web.de","threadId":"27708","inReplyTo":"BANLkTimsfR4LqDAci0Vr+m9uUE_W-7OSAw@mail.gmail.com","subject":"Re: tracking submodules out of main directory.","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-06-28T17:00:30Z","receivedAt":"2011-06-28T17:00:30Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 28.06.2011 12:05, schrieb Alexei Sholik:\n> On 27 June 2011 22:05, Junio C Hamano wrote:\n>> That is what I called \"there is no direct way\". Wouldn't it be nicer if\n>> the .gitmodules file in the superproject said something like\n>>\n>> [module \"project one\"]\n>> path = project1\n>> url = ...\n>> depends = lib1\n>> [module \"lib1\"]\n>> path = lib1\n>> url = ...\n>>\n>> and then \"git submodule init project1\" run by the end user implied running\n>> also \"git submodule init lib1\"?\n> \n> This is a very nice idea. In my workflow, I find it that I more often\n> need to clone a repo _including_ its submodules, because the top-level\n> project won't compile without them. If we had a way to specify\n> dependencies on submodules, `git pull` could automatically init and\n> update them.\n\nWhile Junio's proposition was about initializing submodules that live\nnext to each other you seem to be interested in recursive initialization.\nMy plan is to add a flag to .gitmodules, say \"autoinit\", which will, when\nset, lead to a initialized and checked out submodule on clone.\n\n> If a user really wants to clone only the top-level repo without\n> submodules, git could provide him with an option for `git pull` (like\n> `git pull --shallow`) to do just that. I think this second scenario is\n> less common, so it is more reasonable to have a '--shallow' option for\n> it, instead of '--recursive' counterpart.\n\nApart from the name, where I think \"--recurse-submodules=none\" is more\nconsistent with the other options we have, this is the plan when clone\nlearns to check out submodules too.\n"},{"id":"172186","messageId":"1311792580.2413.82.camel@Naugrim.eriador.com","threadId":"27708","inReplyTo":"4E0A08AE.8090407@web.de","subject":"Re: tracking submodules out of main directory.","fromName":"henri GEIST","fromEmail":"henri.geist@flying-robots.com","sentAt":"2011-07-27T18:49:39Z","receivedAt":"2011-07-27T18:49:39Z","isPatch":false,"sender":{"key":"henri.geist@flying-robots.com","avatar":null},"body":"\tHello,\n\nsorry for the delay but here is a patch to include the feature.\nI work with it and it full fill my needs.\n\nIn hope that some one else will find it useful.\n\n\tHenri GEIST\n\n\n>From 09b7cda863c4443d11808f5b3f1a46ce05aa1e0d Mon Sep 17 00:00:00 2001\nFrom: Henri GEIST \nDate: Wed, 27 Jul 2011 20:16:13 +0200\nSubject: [PATCH] Enabeling (sub)modules linking out of repository.\n\nDepending on there workflow somme people needs to link there repository\nto depend on external modules.\nJust like library could be shared by different programme and other\nlibraries.\nIt's a mean to track dependency between source code projects.\n\nIn the current code it was not possible to add a gitlink to a repository\noutside of the main repository.\n\nThis pach :\n - Enable adding an external git directory.\n - Still forbid to add anything else.\n - Take care of prohibitting git to overright any data outside of the\n current directory.\n - Incrase some tests to validate the new feature.\n\nThis way you can have :\n - Project depending of multiple subprojects themselves depending on\n one third rank common suproject without clash at compilation\n linking.\n - Confidance that all suproject use the same version of the third rank\n subroject (git status will tell you.)\n - All subproject and subsubproject could be esealy worked on there one\n and synchronized after in the big project.\n\nSigned-off-by: Henri GEIST \n---\n builtin/clean.c | 6 ++++--\n path.c | 20 +++++++++++++++++---\n read-cache.c | 14 ++++++++++++++\n setup.c | 10 ++++++++--\n t/t0060-path-utils.sh | 16 ++++++++--------\n test-path-utils.c | 6 ++++--\n 6 files changed, 55 insertions(+), 17 deletions(-)\n\ndiff --git a/builtin/clean.c b/builtin/clean.c\nindex 75697f7..e234e5d 100644\n--- a/builtin/clean.c\n+++ b/builtin/clean.c\n@@ -149,8 +149,10 @@ int cmd_clean(int argc, const char **argv, const char *prefix)\n \t\tif (S_ISDIR(st.st_mode)) {\n \t\t\tstrbuf_addstr(&directory, ent->name);\n \t\t\tqname = quote_path_relative(directory.buf, directory.len, &buf, prefix);\n-\t\t\tif (show_only && (remove_directories ||\n-\t\t\t (matches == MATCHED_EXACTLY))) {\n+\t\t\tif (!strncmp (\"../\", qname, 3)) {\n+\t\t\t\tdie(\"'%s' is outside repository\", qname);\n+\t\t\t} else if (show_only && (remove_directories ||\n+\t\t\t\t (matches == MATCHED_EXACTLY))) {\n \t\t\t\tprintf(_(\"Would remove %s\\n\"), qname);\n \t\t\t} else if (remove_directories ||\n \t\t\t\t (matches == MATCHED_EXACTLY)) {\ndiff --git a/path.c b/path.c\nindex 4d73cc9..daf1573 100644\n--- a/path.c\n+++ b/path.c\n@@ -444,7 +444,8 @@ const char *relative_path(const char *abs, const char *base)\n * - Removes \".\" components.\n * - Removes \"..\" components, and the components the precede them.\n * Returns failure (non-zero) if a \"..\" component appears as first path\n- * component anytime during the normalization. Otherwise, returns success (0).\n+ * component but finish the normalization before.\n+ * Otherwise, returns success (0).\n *\n * Note that this function is purely textual. It does not follow symlinks,\n * verify the existence of the path, or make any system calls.\n@@ -519,13 +520,26 @@ int normalize_path_copy(char *dst, const char *src)\n \t\t * go up one level.\n \t\t */\n \t\tdst--;\t/* go to trailing '/' */\n-\t\tif (dst <= dst0)\n-\t\t\treturn -1;\n+\t\tif (dst <= dst0\n+\t\t || (dst0 + 2 <= dst\n+\t\t\t&& dst[-1] == '.' && dst[-2] == '.'\n+\t\t\t&& (dst0 + 2 == dst || dst[-3] == '/'))) {\n+\t\t\tdst++;\n+\t\t\t*dst++ = '.';\n+\t\t\t*dst++ = '.';\n+\t\t\t*dst++ = '/';\n+\t\t\tcontinue;\n+\t\t}\n \t\t/* Windows: dst[-1] cannot be backslash anymore */\n \t\twhile (dst0 < dst && dst[-1] != '/')\n \t\t\tdst--;\n \t}\n \t*dst = '\\0';\n+\tif (*dst0 == '/')\n+\t\tdst0++;\n+\tif (2 <= strlen (dst0)\n+\t && dst0[0] == '.' && dst0[1] == '.' && dst0[2] == '/')\n+\t\treturn -1;\n \treturn 0;\n }\n \ndiff --git a/read-cache.c b/read-cache.c\nindex 46a9e60..7fb695a 100644\n--- a/read-cache.c\n+++ b/read-cache.c\n@@ -753,6 +753,20 @@ static int verify_dotfile(const char *rest)\n int verify_path(const char *path)\n {\n \tchar c;\n+\tstruct stat buf;\n+\n+\tlstat (path, &buf);\n+\tif (buf.st_mode & S_IFDIR) {\n+\t\tfor (;;) {\n+\t\t\tif (path[0] != '.')\n+\t\t\t\tbreak;\n+\t\t\tif (path[1] != '.')\n+\t\t\t\tbreak;\n+\t\t\tif (path[2] != '/')\n+\t\t\t\tbreak;\n+\t\t\tpath += 3;\n+\t\t}\n+\t}\n \n \tif (has_dos_drive_prefix(path))\n \t\treturn 0;\ndiff --git a/setup.c b/setup.c\nindex 5ea5502..ce7993e 100644\n--- a/setup.c\n+++ b/setup.c\n@@ -8,6 +8,8 @@ char *prefix_path(const char *prefix, int len, const char *path)\n {\n \tconst char *orig = path;\n \tchar *sanitized;\n+\tstruct stat buf;\n+\n \tif (is_absolute_path(orig)) {\n \t\tconst char *temp = real_path(path);\n \t\tsanitized = xmalloc(len + strlen(temp) + 1);\n@@ -18,8 +20,12 @@ char *prefix_path(const char *prefix, int len, const char *path)\n \t\t\tmemcpy(sanitized, prefix, len);\n \t\tstrcpy(sanitized + len, path);\n \t}\n-\tif (normalize_path_copy(sanitized, sanitized))\n-\t\tgoto error_out;\n+\tif (normalize_path_copy(sanitized, sanitized)) {\n+\t\tif (0 != lstat(sanitized, &buf))\n+\t\t\tgoto error_out;\n+\t\tif (!(buf.st_mode & S_IFDIR))\n+\t\t\tgoto error_out;\n+\t}\n \tif (is_absolute_path(orig)) {\n \t\tsize_t root_len, len, total;\n \t\tconst char *work_tree = get_git_work_tree();\ndiff --git a/t/t0060-path-utils.sh b/t/t0060-path-utils.sh\nindex 53cf1f8..b4b9b1f 100755\n--- a/t/t0060-path-utils.sh\n+++ b/t/t0060-path-utils.sh\n@@ -48,12 +48,12 @@ norm_path \"\" \"\"\n norm_path . \"\"\n norm_path ./ \"\"\n norm_path ./. \"\"\n-norm_path ./.. ++failed++\n-norm_path ../. ++failed++\n-norm_path ./../.// ++failed++\n+norm_path ./.. \"../ ++failed++\"\n+norm_path ../. \"../ ++failed++\"\n+norm_path ./../.// \"../ ++failed++\"\n norm_path dir/.. \"\"\n norm_path dir/sub/../.. \"\"\n-norm_path dir/sub/../../.. ++failed++\n+norm_path dir/sub/../../.. \"../ ++failed++\"\n norm_path dir dir\n norm_path dir// dir/\n norm_path ./dir dir\n@@ -73,12 +73,12 @@ norm_path // / POSIX\n norm_path /// / POSIX\n norm_path /. / POSIX\n norm_path /./ / POSIX\n-norm_path /./.. ++failed++ POSIX\n-norm_path /../. ++failed++ POSIX\n-norm_path /./../.// ++failed++ POSIX\n+norm_path /./.. \"/../ ++failed++\" POSIX\n+norm_path /../. \"/../ ++failed++\" POSIX\n+norm_path /./../.// \"/../ ++failed++\" POSIX\n norm_path /dir/.. / POSIX\n norm_path /dir/sub/../.. / POSIX\n-norm_path /dir/sub/../../.. ++failed++ POSIX\n+norm_path /dir/sub/../../.. \"/../ ++failed++\" POSIX\n norm_path /dir /dir POSIX\n norm_path /dir// /dir/ POSIX\n norm_path /./dir /dir POSIX\ndiff --git a/test-path-utils.c b/test-path-utils.c\nindex e767159..ba6c8ac 100644\n--- a/test-path-utils.c\n+++ b/test-path-utils.c\n@@ -5,8 +5,10 @@ int main(int argc, char **argv)\n \tif (argc == 3 && !strcmp(argv[1], \"normalize_path_copy\")) {\n \t\tchar *buf = xmalloc(PATH_MAX + 1);\n \t\tint rv = normalize_path_copy(buf, argv[2]);\n-\t\tif (rv)\n-\t\t\tbuf = \"++failed++\";\n+\t\tif (rv) {\n+\t\t\tfputs(buf, stdout);\n+\t\t\tbuf = \" ++failed++\";\n+\t\t}\n \t\tputs(buf);\n \t\treturn 0;\n \t}\n-- \n1.7.2.5\n"},{"id":"172243","messageId":"1311843465.3734.40.camel@Naugrim.eriador.com","threadId":"27708","inReplyTo":"1311792580.2413.82.camel@Naugrim.eriador.com","subject":"Re: tracking submodules out of main directory.","fromName":"henri GEIST","fromEmail":"henri.geist@flying-robots.com","sentAt":"2011-07-28T08:57:45Z","receivedAt":"2011-07-28T08:57:45Z","isPatch":false,"sender":{"key":"henri.geist@flying-robots.com","avatar":null},"body":"\tHello,\n\nThe same with some orthographique corrections by\nSverre Rabbelier (unofficial)\n\n\n>From 9a4e10fbb884583638c1651cc6cb98e0ce59cb9b Mon Sep 17 00:00:00 2001\nFrom: Henri GEIST \nDate: Thu, 28 Jul 2011 10:15:55 +0200\nSubject: [PATCH] Enabeling (sub)modules linking out of repository.\n\nDepending on there workflow some people needs to link there repository\nto depend on external modules.\nJust like library could be shared by different program and other libraries.\nIt's a means to track dependency between source code projects.\n\nIn the current code it was not possible to add a gitlink to a repository\noutside of the main repository.\n\nThis pach :\n - Enables adding an external git directory.\n - Still forbids to add anything else.\n - Takes care of prohibitting git to overwrite any data outside of the\n current directory.\n - Increase some tests to validate the new feature.\n\nThis way you can have :\n - Project depending of multiple subprojects themselves depending on\n one third rank common suproject without clashing at compilation\n linking.\n - Confidence that all suproject use the same version of the third rank\n subproject (git status will tell you.)\n - All subproject and subsubproject could be easily worked on there one\n and synchronized after in the big project.\n\nSigned-off-by: Henri GEIST \n---\n builtin/clean.c | 6 ++++--\n path.c | 20 +++++++++++++++++---\n read-cache.c | 14 ++++++++++++++\n setup.c | 10 ++++++++--\n t/t0060-path-utils.sh | 16 ++++++++--------\n test-path-utils.c | 6 ++++--\n 6 files changed, 55 insertions(+), 17 deletions(-)\n\ndiff --git a/builtin/clean.c b/builtin/clean.c\nindex 75697f7..e234e5d 100644\n--- a/builtin/clean.c\n+++ b/builtin/clean.c\n@@ -149,8 +149,10 @@ int cmd_clean(int argc, const char **argv, const char *prefix)\n \t\tif (S_ISDIR(st.st_mode)) {\n \t\t\tstrbuf_addstr(&directory, ent->name);\n \t\t\tqname = quote_path_relative(directory.buf, directory.len, &buf, prefix);\n-\t\t\tif (show_only && (remove_directories ||\n-\t\t\t (matches == MATCHED_EXACTLY))) {\n+\t\t\tif (!strncmp (\"../\", qname, 3)) {\n+\t\t\t\tdie(\"'%s' is outside repository\", qname);\n+\t\t\t} else if (show_only && (remove_directories ||\n+\t\t\t\t (matches == MATCHED_EXACTLY))) {\n \t\t\t\tprintf(_(\"Would remove %s\\n\"), qname);\n \t\t\t} else if (remove_directories ||\n \t\t\t\t (matches == MATCHED_EXACTLY)) {\ndiff --git a/path.c b/path.c\nindex 4d73cc9..daf1573 100644\n--- a/path.c\n+++ b/path.c\n@@ -444,7 +444,8 @@ const char *relative_path(const char *abs, const char *base)\n * - Removes \".\" components.\n * - Removes \"..\" components, and the components the precede them.\n * Returns failure (non-zero) if a \"..\" component appears as first path\n- * component anytime during the normalization. Otherwise, returns success (0).\n+ * component but finish the normalization before.\n+ * Otherwise, returns success (0).\n *\n * Note that this function is purely textual. It does not follow symlinks,\n * verify the existence of the path, or make any system calls.\n@@ -519,13 +520,26 @@ int normalize_path_copy(char *dst, const char *src)\n \t\t * go up one level.\n \t\t */\n \t\tdst--;\t/* go to trailing '/' */\n-\t\tif (dst <= dst0)\n-\t\t\treturn -1;\n+\t\tif (dst <= dst0\n+\t\t || (dst0 + 2 <= dst\n+\t\t\t&& dst[-1] == '.' && dst[-2] == '.'\n+\t\t\t&& (dst0 + 2 == dst || dst[-3] == '/'))) {\n+\t\t\tdst++;\n+\t\t\t*dst++ = '.';\n+\t\t\t*dst++ = '.';\n+\t\t\t*dst++ = '/';\n+\t\t\tcontinue;\n+\t\t}\n \t\t/* Windows: dst[-1] cannot be backslash anymore */\n \t\twhile (dst0 < dst && dst[-1] != '/')\n \t\t\tdst--;\n \t}\n \t*dst = '\\0';\n+\tif (*dst0 == '/')\n+\t\tdst0++;\n+\tif (2 <= strlen (dst0)\n+\t && dst0[0] == '.' && dst0[1] == '.' && dst0[2] == '/')\n+\t\treturn -1;\n \treturn 0;\n }\n \ndiff --git a/read-cache.c b/read-cache.c\nindex 46a9e60..7fb695a 100644\n--- a/read-cache.c\n+++ b/read-cache.c\n@@ -753,6 +753,20 @@ static int verify_dotfile(const char *rest)\n int verify_path(const char *path)\n {\n \tchar c;\n+\tstruct stat buf;\n+\n+\tlstat (path, &buf);\n+\tif (buf.st_mode & S_IFDIR) {\n+\t\tfor (;;) {\n+\t\t\tif (path[0] != '.')\n+\t\t\t\tbreak;\n+\t\t\tif (path[1] != '.')\n+\t\t\t\tbreak;\n+\t\t\tif (path[2] != '/')\n+\t\t\t\tbreak;\n+\t\t\tpath += 3;\n+\t\t}\n+\t}\n \n \tif (has_dos_drive_prefix(path))\n \t\treturn 0;\ndiff --git a/setup.c b/setup.c\nindex 5ea5502..ce7993e 100644\n--- a/setup.c\n+++ b/setup.c\n@@ -8,6 +8,8 @@ char *prefix_path(const char *prefix, int len, const char *path)\n {\n \tconst char *orig = path;\n \tchar *sanitized;\n+\tstruct stat buf;\n+\n \tif (is_absolute_path(orig)) {\n \t\tconst char *temp = real_path(path);\n \t\tsanitized = xmalloc(len + strlen(temp) + 1);\n@@ -18,8 +20,12 @@ char *prefix_path(const char *prefix, int len, const char *path)\n \t\t\tmemcpy(sanitized, prefix, len);\n \t\tstrcpy(sanitized + len, path);\n \t}\n-\tif (normalize_path_copy(sanitized, sanitized))\n-\t\tgoto error_out;\n+\tif (normalize_path_copy(sanitized, sanitized)) {\n+\t\tif (0 != lstat(sanitized, &buf))\n+\t\t\tgoto error_out;\n+\t\tif (!(buf.st_mode & S_IFDIR))\n+\t\t\tgoto error_out;\n+\t}\n \tif (is_absolute_path(orig)) {\n \t\tsize_t root_len, len, total;\n \t\tconst char *work_tree = get_git_work_tree();\ndiff --git a/t/t0060-path-utils.sh b/t/t0060-path-utils.sh\nindex 53cf1f8..b4b9b1f 100755\n--- a/t/t0060-path-utils.sh\n+++ b/t/t0060-path-utils.sh\n@@ -48,12 +48,12 @@ norm_path \"\" \"\"\n norm_path . \"\"\n norm_path ./ \"\"\n norm_path ./. \"\"\n-norm_path ./.. ++failed++\n-norm_path ../. ++failed++\n-norm_path ./../.// ++failed++\n+norm_path ./.. \"../ ++failed++\"\n+norm_path ../. \"../ ++failed++\"\n+norm_path ./../.// \"../ ++failed++\"\n norm_path dir/.. \"\"\n norm_path dir/sub/../.. \"\"\n-norm_path dir/sub/../../.. ++failed++\n+norm_path dir/sub/../../.. \"../ ++failed++\"\n norm_path dir dir\n norm_path dir// dir/\n norm_path ./dir dir\n@@ -73,12 +73,12 @@ norm_path // / POSIX\n norm_path /// / POSIX\n norm_path /. / POSIX\n norm_path /./ / POSIX\n-norm_path /./.. ++failed++ POSIX\n-norm_path /../. ++failed++ POSIX\n-norm_path /./../.// ++failed++ POSIX\n+norm_path /./.. \"/../ ++failed++\" POSIX\n+norm_path /../. \"/../ ++failed++\" POSIX\n+norm_path /./../.// \"/../ ++failed++\" POSIX\n norm_path /dir/.. / POSIX\n norm_path /dir/sub/../.. / POSIX\n-norm_path /dir/sub/../../.. ++failed++ POSIX\n+norm_path /dir/sub/../../.. \"/../ ++failed++\" POSIX\n norm_path /dir /dir POSIX\n norm_path /dir// /dir/ POSIX\n norm_path /./dir /dir POSIX\ndiff --git a/test-path-utils.c b/test-path-utils.c\nindex e767159..ba6c8ac 100644\n--- a/test-path-utils.c\n+++ b/test-path-utils.c\n@@ -5,8 +5,10 @@ int main(int argc, char **argv)\n \tif (argc == 3 && !strcmp(argv[1], \"normalize_path_copy\")) {\n \t\tchar *buf = xmalloc(PATH_MAX + 1);\n \t\tint rv = normalize_path_copy(buf, argv[2]);\n-\t\tif (rv)\n-\t\t\tbuf = \"++failed++\";\n+\t\tif (rv) {\n+\t\t\tfputs(buf, stdout);\n+\t\t\tbuf = \" ++failed++\";\n+\t\t}\n \t\tputs(buf);\n \t\treturn 0;\n \t}\n-- \n1.7.2.5\n"},{"id":"172273","messageId":"4E3192D4.5000504@web.de","threadId":"27708","inReplyTo":"1311843465.3734.40.camel@Naugrim.eriador.com","subject":"Re: tracking submodules out of main directory.","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-07-28T16:48:20Z","receivedAt":"2011-07-28T16:48:20Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 28.07.2011 10:57, schrieb henri GEIST:\n> In the current code it was not possible to add a gitlink to a repository\n> outside of the main repository.\n\nMe thinks this is a *feature* this patch removes (as I understand it it was\na major design decision that everything /inside/ a directory is controlled\nby git).\n\n> This pach :\n\n> - Still forbids to add anything else.\n\nWhy? If you let submodules live outside the tree I don't see any reason why\nregular files shouldn't live there too (Disclaimer: I d not think that would\nbe a good idea either ;-).\n\nWhat you want looks like this:\n\n-+- lib1 #registered as submodule of project1 *and* project2 but not here\n +- project1 # submodule of the superproject\n | +- ../lib1\n +- project2 # submodule of the superproject\n +- ../lib1\n\nYou are opening a can of worms by having two different repos point to the same\nsubmodule living in a third repo (which also happens to be their superproject\nand must somehow ignore it). You'll have two SHA1s for a single submodule;\n\"git submodule foreach --recursive\" will have interesting results too; and so\non. Not good.\n\nWhat about solving that with a \"ln -s ../lib1\" in \"project1\" and \"project2\"\n(you seem to need that for your build environment) and adding the submodule\n\"lib1\" to the superproject just like \"project1\" and \"project2\"?\n"},{"id":"172322","messageId":"1311932377.3734.182.camel@Naugrim.eriador.com","threadId":"27708","inReplyTo":"4E3192D4.5000504@web.de","subject":"Re: tracking submodules out of main directory.","fromName":"henri GEIST","fromEmail":"henri.geist@flying-robots.com","sentAt":"2011-07-29T09:39:37Z","receivedAt":"2011-07-29T09:39:37Z","isPatch":false,"sender":{"key":"henri.geist@flying-robots.com","avatar":null},"body":"Le jeudi 28 juillet 2011 à 18:48 +0200, Jens Lehmann a écrit :\n> Am 28.07.2011 10:57, schrieb henri GEIST:\n> > In the current code it was not possible to add a gitlink to a repository\n> > outside of the main repository.\n> \n\nOf course that is why I have done the patch.\n\n> Me thinks this is a *feature* this patch removes (as I understand it it was\n> a major design decision that everything /inside/ a directory is controlled\n> by git).\n> \n\nThat is still the case.\nIt is not a matter of disabling any control of git in its own\nrepository.\nIt is just a matter of adding inside the git repository a reference\n(dependency) to an other git repository.\n\n> > This pach :\n> \n> > - Still forbids to add anything else.\n> \n> Why? If you let submodules live outside the tree I don't see any reason why\n> regular files shouldn't live there too (Disclaimer: I d not think that would\n> be a good idea either ;-).\n> \n\nthere is regular file in the submodule repository but they are controled\nby the submodule itself. Then the main repository do not need to handle\nthem.\n\nJust like you I think that regular file should not be touche outside of\nthe repository by git.\nBecause in this case it is not just a reference that is managed but the\nfile itself. And this way there is a risk to overwrite some data not\nunder revision control outside of the repository.\n\n> What you want looks like this:\n> \n> -+- lib1 #registered as submodule of project1 *and* project2 but not here\n> +- project1 # submodule of the superproject\n> | +- ../lib1\n> +- project2 # submodule of the superproject\n> +- ../lib1\n> \n\nIn fact no.\nWhat I want is to have this:\n\n-+- lib1\n +- project1\n +- project2\n\nWith :\n - lib1 not knowing anything about projects 1 & 2\n - project1 not knowing anything about project2 and vice et versa\n - project1 knowing that it need lib1 in version N.\n - project2 knowing that it need lib1 in version M.\n\nI know that means a conflict in the required lib version but it is\nrequired by the independence of projects 1 & 2 which do not have to know\nwhat happen in the other one.\n\nAnd in fact it is just what I want, it enable me if I decide to work on\nan optional \"BigProject\" depending on both project 1 & 2.\n\nThen If lib1 is in version M:\n - a git status in project2 will say nothing\n - a git status in project1 will say\n \"modified: ../lib1 (modified content)\n - a git status in BigProject will say\n \"modified: ../project1 (modified content)\n\nThen I know that I need to update project1 to work with the last version\nM of lib1.\n\n> You are opening a can of worms by having two different repos point to the same\n> submodule living in a third repo (which also happens to be their superproject\n> and must somehow ignore it). You'll have two SHA1s for a single submodule;\n> \"git submodule foreach --recursive\" will have interesting results too; and so\n> on. Not good.\n> \n\nAs I just said before it is my purpose to do it like that.\n\nIf you want to avoid this just put (project1 lib1) and (project2 lib2)\nin different places on your hard disk\n\nLet say a concret exemple\n\n3 different teams work on libtiff, libpng, and libjpeg they are totally\nunrelated.\n\nOne more team is working on the \"gimp\". And they need those 3 libs in\nspecific versions not necessarily there heads.\n\nOne other unrelated team is working on \"gqview\" and need the same libs\nin other specifics versions (Why should they know what te gimp team\ndoes)\n\nNeither \"gimp\" and \"gqview\" project will contain directory with those\nlibs inside. They just depend on them.\n\nAnd the last team work on the gnome project which need the \"gimp\" and\n\"gqview\". It will be this team witch have to care about having both\n\"gimp\" and \"gqview\" sharing the same libs version>\nAnd has well the gnome project will not contain \"gqview\" and \"gimp\" in\nits own tree.\nIt will also depend on them.\n\nIt is just the same with aptitude on debian.\nEach package know there dependency by themselves, does not contain there\ndependencies, and do not need a bigger superpackage to tell them what\nare there own dependencies.\n\n> What about solving that with a \"ln -s ../lib1\" in \"project1\" and \"project2\"\n> (you seem to need that for your build environment) and adding the submodule\n> \"lib1\" to the superproject just like \"project1\" and \"project2\"?\n> \n\nFor my build environment I do not use simlinks.\nI use tu put :\n\n#include \"../lib1/lib1.h\"\nin project1/project1.c\n\nAnd even if I do not face this problem myself, simlinks do not work so\nwell on Windows.\n\nAnd Still I realy want to have every project knowing there own\ndependency by themselves and not needing an external superproject to\ntell them what they need.\n\n Henri GEIST\n"},{"id":"172391","messageId":"4E34122B.5020509@web.de","threadId":"27708","inReplyTo":"1311932377.3734.182.camel@Naugrim.eriador.com","subject":"Re: tracking submodules out of main directory.","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-07-30T14:16:11Z","receivedAt":"2011-07-30T14:16:11Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 29.07.2011 11:39, schrieb henri GEIST:\n> Le jeudi 28 juillet 2011 à 18:48 +0200, Jens Lehmann a écrit :\n>> Am 28.07.2011 10:57, schrieb henri GEIST:\n>>> In the current code it was not possible to add a gitlink to a repository\n>>> outside of the main repository.\n> \n> Of course that is why I have done the patch.\n> \n>> Me thinks this is a *feature* this patch removes (as I understand it it was\n>> a major design decision that everything /inside/ a directory is controlled\n>> by git).\n> \n> That is still the case.\n\nNo, as \"everything /inside/ a directory\" also means \"nothing /outside/ that\ndirectory\" in this context.\n\n> It is not a matter of disabling any control of git in its own\n> repository.\n> It is just a matter of adding inside the git repository a reference\n> (dependency) to an other git repository.\n\n... which you want to have *outside* of the containing repository! That will\nthen be registered in other git repositories too in your model, which gets\nrid of the \"one file/submodule, one repo\" assumption we now have and will\nintroduce ambiguities which are *really* hard to handle.\n\n>>> This pach :\n>> \n>>> - Still forbids to add anything else.\n>>\n>> Why? If you let submodules live outside the tree I don't see any reason why\n>> regular files shouldn't live there too (Disclaimer: I d not think that would\n>> be a good idea either ;-).\n> \n> there is regular file in the submodule repository but they are controled\n> by the submodule itself. Then the main repository do not need to handle\n> them.\n> \n> Just like you I think that regular file should not be touche outside of\n> the repository by git.\n\nNo, I think we should /either/ allow gitlinks *and* files to live outside of\nthe repository /or/ *none* of them, as they have a lot in common (and I'm\nworking on making them to behave as similar as possible). And in the use case\nyou describe here it is totally irrelevant if you dependency consists of a\ndirectory tree in a submodule (= a bunch of files) or just a single file (say\na header containing project wide definitions).\n\n> Because in this case it is not just a reference that is managed but the\n> file itself. And this way there is a risk to overwrite some data not\n> under revision control outside of the repository.\n\nYou have the same risk when a gitlink points outside, as a submodule is a\nway of controlling a bunch of files through that reference. And the file\nwould be under version control in the repository where it is registered, no?\n\n>> What you want looks like this:\n>>\n>> -+- lib1 #registered as submodule of project1 *and* project2 but not here\n>> +- project1 # submodule of the superproject\n>> | +- ../lib1\n>> +- project2 # submodule of the superproject\n>> +- ../lib1\n> \n> In fact no.\n> What I want is to have this:\n> \n> -+- lib1\n> +- project1\n> +- project2\n> \n> With :\n> - lib1 not knowing anything about projects 1 & 2\n> - project1 not knowing anything about project2 and vice et versa\n> - project1 knowing that it need lib1 in version N.\n> - project2 knowing that it need lib1 in version M.\n\nRight, I should have explained the \"../lib1\" entries better.\n\n> I know that means a conflict in the required lib version but it is\n> required by the independence of projects 1 & 2 which do not have to know\n> what happen in the other one.\n> \n> And in fact it is just what I want, it enable me if I decide to work on\n> an optional \"BigProject\" depending on both project 1 & 2.\n> \n> Then If lib1 is in version M:\n> - a git status in project2 will say nothing\n> - a git status in project1 will say\n> \"modified: ../lib1 (modified content)\n> - a git status in BigProject will say\n> \"modified: ../project1 (modified content)\n> \n> Then I know that I need to update project1 to work with the last version\n> M of lib1.\n\nMaybe no update for project1 is needed, because M only contains a bugfix\nwhich doesn't even need a recompilation of project1. But now you need to\nadd a commit to project1 nonetheless with a message like \"Updated lib1\nwith a bugfix which is needed by project2\" which makes your idea of\nindependent submodules break down.\n\n>> You are opening a can of worms by having two different repos point to the same\n>> submodule living in a third repo (which also happens to be their superproject\n>> and must somehow ignore it). You'll have two SHA1s for a single submodule;\n>> \"git submodule foreach --recursive\" will have interesting results too; and so\n>> on. Not good.\n> \n> As I just said before it is my purpose to do it like that.\n\nI understood that, but what are you proposing to do to solve all the\nproblems your approach introduces? You can't just hand wave them away.\n\n> Let say a concret exemple\n> \n> 3 different teams work on libtiff, libpng, and libjpeg they are totally\n> unrelated.\n> \n> One more team is working on the \"gimp\". And they need those 3 libs in\n> specific versions not necessarily there heads.\n> \n> One other unrelated team is working on \"gqview\" and need the same libs\n> in other specifics versions (Why should they know what te gimp team\n> does)\n> \n> Neither \"gimp\" and \"gqview\" project will contain directory with those\n> libs inside. They just depend on them.\n> \n> And the last team work on the gnome project which need the \"gimp\" and\n> \"gqview\". It will be this team witch have to care about having both\n> \"gimp\" and \"gqview\" sharing the same libs version>\n> And has well the gnome project will not contain \"gqview\" and \"gimp\" in\n> its own tree.\n> It will also depend on them.\n\nCool, that is a real life example resembling what we have a my dayjob. But\na \"gimp\" and \"gqview\" project will only have dependencies like \"use libpng\nof version 1.2.3 or newer (because we need a feature/bugfix introduced\nthere)\" and won't be tied to a special version of that library. This means\nthey need a dependency like \"SHA1 or newer\" instead of \"exactly this SHA1\".\n\n> It is just the same with aptitude on debian.\n> Each package know there dependency by themselves, does not contain there\n> dependencies, and do not need a bigger superpackage to tell them what\n> are there own dependencies.\n\nAnd this is a very good point for the \"version x.yy-z *or newer*\" argument,\nthey are /never/ tied to the /exact/ x.yy-z version, as that would make the\ndependencies pretty much unusable. They use a \"newer than x.yy-z\" scheme.\n\n>> What about solving that with a \"ln -s ../lib1\" in \"project1\" and \"project2\"\n>> (you seem to need that for your build environment) and adding the submodule\n>> \"lib1\" to the superproject just like \"project1\" and \"project2\"?\n>>\n> \n> For my build environment I do not use simlinks.\n> I use tu put :\n> \n> #include \"../lib1/lib1.h\"\n> in project1/project1.c\n> \n> And even if I do not face this problem myself, simlinks do not work so\n> well on Windows.\n\nAgreed.\n\n> And Still I realy want to have every project knowing there own\n> dependency by themselves and not needing an external superproject to\n> tell them what they need.\n\nI want to have that too! I'm just convinced using a gitlink to achieve that\nis wrong in so many ways. I'd rather prefer to express such dependencies in\nsomething like a config file, and I believe they should not be as strict as\n\"I need exactly that version\" but rather like \"this version or newer (and by\nthe way: we of course only tested that specific version ;-)\". These\ndependencies could then be checked and displayed by git status.\n"},{"id":"172413","messageId":"1312062927.3261.334.camel@Naugrim.eriador.com","threadId":"27708","inReplyTo":"4E34122B.5020509@web.de","subject":"Re: tracking submodules out of main directory.","fromName":"henri GEIST","fromEmail":"henri.geist@flying-robots.com","sentAt":"2011-07-30T21:55:27Z","receivedAt":"2011-07-30T21:55:27Z","isPatch":false,"sender":{"key":"henri.geist@flying-robots.com","avatar":null},"body":"Le samedi 30 juillet 2011 à 16:16 +0200, Jens Lehmann a écrit :\n> Am 29.07.2011 11:39, schrieb henri GEIST:\n> > Le jeudi 28 juillet 2011 à 18:48 +0200, Jens Lehmann a écrit :\n> >> Am 28.07.2011 10:57, schrieb henri GEIST:\n> > \n> > It is not a matter of disabling any control of git in its own\n> > repository.\n> > It is just a matter of adding inside the git repository a reference\n> > (dependency) to an other git repository.\n> \n> ... which you want to have *outside* of the containing repository!\n\nyes\n\n> That will then be registered in other git repositories too in your model,\n> which gets rid of the \"one file/submodule, one repo\" assumption we now have\n> and will introduce ambiguities which are *really* hard to handle.\n> \n\nI am sorry, I am not a native English speaker. This sentence is to\ncomplex for me. And google translator is of no help in this case.\n\n> >>> This pach :\n> >> \n> >>> - Still forbids to add anything else.\n> >>\n> >> Why? If you let submodules live outside the tree I don't see any reason why\n> >> regular files shouldn't live there too (Disclaimer: I d not think that would\n> >> be a good idea either ;-).\n> > \n> > there is regular file in the submodule repository but they are controled\n> > by the submodule itself. Then the main repository do not need to handle\n> > them.\n> > \n> > Just like you I think that regular file should not be touche outside of\n> > the repository by git.\n> \n> No, I think we should /either/ allow gitlinks *and* files to live outside of\n> the repository /or/ *none* of them, as they have a lot in common (and I'm\n> working on making them to behave as similar as possible). And in the use case\n> you describe here it is totally irrelevant if you dependency consists of a\n> directory tree in a submodule (= a bunch of files) or just a single file (say\n> a header containing project wide definitions).\n> \n\nYes they have a lot in common but they still have a different nature.\ngit links pointer (not files on a hard-drive) to something which has a\nspecial meaning for git, (a git repository).\nJust like the .git directory which also have a special handling.\n\nBut I agree the step is really weak before enabling to put any regular\nfile outside of the directory.\nI do not see any reasonable workflow (to my eyes) for it but' maybe some\nday someone will came with a justifiable workflow which need it. we will\nnever know.\n\nBut in this case we need solve some questions :\n - Will we extend git status signaling untracked files out of the\n repository ?\n - What will do git-clean ? it is already dangerous inside the\n repository. and it will be worst if it can access outside of it.\n\nMay be some other points that I do not see for the moment.\n\n> > Because in this case it is not just a reference that is managed but the\n> > file itself. And this way there is a risk to overwrite some data not\n> > under revision control outside of the repository.\n> \n> You have the same risk when a gitlink points outside, as a submodule is a\n> way of controlling a bunch of files through that reference. And the file\n> would be under version control in the repository where it is registered, no?\n> \n\nI agree on this point.\n\nBut they are still confined in an another git repository not\ndisseminated all over the file system.\nAnd it never corrupt this pointed repository. just ask it to do by it's\nown regular git commands.\n\nIn fact you can argue that it can disseminate some complete git\nrepository anywhere in the file system.\nAnd you will be right. (nothing is perfect.)\n\nI can do a second patch to prevent git submodule command to make clones\noutside of the repository.\nIt will requires the user to do those clones manually.\nIn fact this is already what I do.\nMy only use of this is to track dependencies.\n \n> > And in fact it is just what I want, it enable me if I decide to work on\n> > an optional \"BigProject\" depending on both project 1 & 2.\n> > \n> > Then If lib1 is in version M:\n> > - a git status in project2 will say nothing\n> > - a git status in project1 will say\n> > \"modified: ../lib1 (modified content)\n> > - a git status in BigProject will say\n> > \"modified: ../project1 (modified content)\n> > \n> > Then I know that I need to update project1 to work with the last version\n> > M of lib1.\n> \n> Maybe no update for project1 is needed, because M only contains a bugfix\n> which doesn't even need a recompilation of project1. But now you need to\n> add a commit to project1 nonetheless with a message like \"Updated lib1\n> with a bugfix which is needed by project2\" which makes your idea of\n> independent submodules break down.\n> \n\nIn fact I work ni the world of \"high integrity programming\" then It is\njust what I need.\nIf there is a bugfix in any library, used by the program it is no more\nthe same program.\nI need the \"SHA1\" to correspond to the exact and complete source code\ninvolved in my executable.\n\nAnd this way the \"SHA1\" of the project sign the \"SHA1\" of the\nlibraries. \n\n> >> You are opening a can of worms by having two different repos point to the same\n> >> submodule living in a third repo (which also happens to be their superproject\n> >> and must somehow ignore it). You'll have two SHA1s for a single submodule;\n> >> \"git submodule foreach --recursive\" will have interesting results too; and so\n> >> on. Not good.\n> > \n> > As I just said before it is my purpose to do it like that.\n> \n> I understood that, but what are you proposing to do to solve all the\n> problems your approach introduces? You can't just hand wave them away.\n> \n\nThere is some solutions :\n\n - First it is one more **feature** if it does not correspond to your\n work flow it does not prevent you to work exactly the way you did\n until now.\n\n - Second if you want to use the feature but not want to have the\n conflict **feature** (for me it is one), just put the independent\n project with there libs in different directory\n\n -+- foo -+- lib1 (in version N)\n | +- project1\n |\n +- bar -+- lib1 (in version M)\n +- project2\n\n - Third if you really need to have project 1 & 2 in the same\n directory foo, that means they are needed by a third BigProject in\n the same directory foo depending on project 1 & 2.\n And then you really need git to declare a conflict.\n\n> > Let say a concret exemple\n> > \n> > 3 different teams work on libtiff, libpng, and libjpeg they are totally\n> > unrelated.\n> > \n> > One more team is working on the \"gimp\". And they need those 3 libs in\n> > specific versions not necessarily there heads.\n> > \n> > One other unrelated team is working on \"gqview\" and need the same libs\n> > in other specifics versions (Why should they know what te gimp team\n> > does)\n> > \n> > Neither \"gimp\" and \"gqview\" project will contain directory with those\n> > libs inside. They just depend on them.\n> > \n> > And the last team work on the gnome project which need the \"gimp\" and\n> > \"gqview\". It will be this team witch have to care about having both\n> > \"gimp\" and \"gqview\" sharing the same libs version>\n> > And has well the gnome project will not contain \"gqview\" and \"gimp\" in\n> > its own tree.\n> > It will also depend on them.\n> \n> Cool, that is a real life example resembling what we have a my dayjob. But\n> a \"gimp\" and \"gqview\" project will only have dependencies like \"use libpng\n> of version 1.2.3 or newer (because we need a feature/bugfix introduced\n> there)\" and won't be tied to a special version of that library. This means\n> they need a dependency like \"SHA1 or newer\" instead of \"exactly this SHA1\".\n> \n\nIt is useful and simpler to work like this but could introduce some\nbugs.\n\nThe \"gimp\" team has tested it with libpng 1.2.3 and maybe know that it\ndid not work with previous versions but if they do not have any crystal\nball they never know if newer versions will not break something.\nIn fact I doubt that the first version of gimp will work with the last\nversion of libpng.\n\n> > It is just the same with aptitude on debian.\n> > Each package know there dependency by themselves, does not contain there\n> > dependencies, and do not need a bigger superpackage to tell them what\n> > are there own dependencies.\n> \n> And this is a very good point for the \"version x.yy-z *or newer*\" argument,\n> they are /never/ tied to the /exact/ x.yy-z version, as that would make the\n> dependencies pretty much unusable. They use a \"newer than x.yy-z\" scheme.\n> \n\nIt is an other feature that the one I need.\nBut it is a good idea.\n\nNothing prevent us to make a patch to add a new test in git status to\nsee if the current SHA1 in the libpng repository has the SHA1 of the\ngitlink in the gimp in its ancestor.\n\n\n> \n> > And Still I realy want to have every project knowing there own\n> > dependency by themselves and not needing an external superproject to\n> > tell them what they need.\n> \n> I want to have that too! I'm just convinced using a gitlink to achieve that\n> is wrong in so many ways. I'd rather prefer to express such dependencies in\n> something like a config file, and I believe they should not be as strict as\n> \"I need exactly that version\" but rather like \"this version or newer (and by\n> the way: we of course only tested that specific version ;-)\". These\n> dependencies could then be checked and displayed by git status.\n> \n\nIt effectively could be in a config file it seem good to me as well.\n\nBut if git handle this config file.\nUpdate it on a \"git add ../libpng && git commit\"\nAnd control the matching between the project and libraries on\n\"git status\">\n\nI can not see the difference with a gitlink.\n\n\tHenri GEIST\n"},{"id":"172591","messageId":"4E370107.3050002@web.de","threadId":"27708","inReplyTo":"1312062927.3261.334.camel@Naugrim.eriador.com","subject":"Re: tracking submodules out of main directory.","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-08-01T19:39:51Z","receivedAt":"2011-08-01T19:39:51Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 30.07.2011 23:55, schrieb henri GEIST:\n> Le samedi 30 juillet 2011 à 16:16 +0200, Jens Lehmann a écrit :\n>> Am 29.07.2011 11:39, schrieb henri GEIST:\n>>> Le jeudi 28 juillet 2011 à 18:48 +0200, Jens Lehmann a écrit :\n>>>> Am 28.07.2011 10:57, schrieb henri GEIST:\n>>>\n>>> It is not a matter of disabling any control of git in its own\n>>> repository.\n>>> It is just a matter of adding inside the git repository a reference\n>>> (dependency) to an other git repository.\n>>\n>> ... which you want to have *outside* of the containing repository!\n> \n> yes\n> \n>> That will then be registered in other git repositories too in your model,\n>> which gets rid of the \"one file/submodule, one repo\" assumption we now have\n>> and will introduce ambiguities which are *really* hard to handle.\n> \n> I am sorry, I am not a native English speaker. This sentence is to\n> complex for me. And google translator is of no help in this case.\n\nYour proposal of letting multiple gitlinks in different repos point to the\nsame submodule will break the assumption that each file is only handled by\na single git repo. For example when you have a conflict and do a \"git\nsubmodule update --recursive\" in the superproject, the SHA1 used for \"lib\"\nwill depend on the alphabetical order of \"project1\" and \"project2\". And\nnormally after running \"git submodule update --recursive\" you expect all\nsubmodules of the superproject to be clean. But your change breaks this\nexpectation, it will still contain unclean submodule entries even though\nyou just told git it should clean them. What will a \"git submodule sync\n--recursive\" do when \"project1\" and \"project2\" use different urls in their\n.gitmodules? And so on.\n\nCommands won't always behave like you expect them to and sometimes will\ngive different results just because different names are used. That's what\nI meant with ambiguities and that's why I don't think gitlinks are the\nright method here.\n\n> But I agree the step is really weak before enabling to put any regular\n> file outside of the directory.\n> I do not see any reasonable workflow (to my eyes) for it but' maybe some\n> day someone will came with a justifiable workflow which need it. we will\n> never know.\n> \n> But in this case we need solve some questions :\n> - Will we extend git status signaling untracked files out of the\n> repository ?\n\nI don't think that would work well.\n\n> - What will do git-clean ? it is already dangerous inside the\n> repository. and it will be worst if it can access outside of it.\n\nHopefully git clean will learn the --recurse-submodules option in the not\ntoo distant future, then you will have just the same danger for the files\ninside a submodule.\n\n>>> Because in this case it is not just a reference that is managed but the\n>>> file itself. And this way there is a risk to overwrite some data not\n>>> under revision control outside of the repository.\n>>\n>> You have the same risk when a gitlink points outside, as a submodule is a\n>> way of controlling a bunch of files through that reference. And the file\n>> would be under version control in the repository where it is registered, no?\n> \n> I agree on this point.\n> \n> But they are still confined in an another git repository not\n> disseminated all over the file system.\n> And it never corrupt this pointed repository. just ask it to do by it's\n> own regular git commands.\n\nThe only difference here is that a submodule can contain more than one file,\nbut you can corrupt those files just as easily as a single file using git\ncommands.\n\n> In fact you can argue that it can disseminate some complete git\n> repository anywhere in the file system.\n> And you will be right. (nothing is perfect.)\n\nI'm not concerned about not being perfect (nothing is perfect), but it is\ndangerous.\n\n> I can do a second patch to prevent git submodule command to make clones\n> outside of the repository.\n> It will requires the user to do those clones manually.\n> In fact this is already what I do.\n> My only use of this is to track dependencies.\n\nBut gitlinks are more than simple dependencies, they are followed! \"git\nsubmodule\", status, diff and fetch already follow them. push is learning\nthat right now. checkout, reset, merge and friends are being taught that\ntoo (see the enhance_submodule branch in my github repo for the current\nstate). So a gitlink is more than just a simple reference, it is followed\nby a lot of commands and the submodule it points to is manipulated by\nthose commands. We had a patch for \"git archive --recurse-submodules\" on\nthe list, what will that do when used in \"project1\"?\n\n>>> And in fact it is just what I want, it enable me if I decide to work on\n>>> an optional \"BigProject\" depending on both project 1 & 2.\n>>>\n>>> Then If lib1 is in version M:\n>>> - a git status in project2 will say nothing\n>>> - a git status in project1 will say\n>>> \"modified: ../lib1 (modified content)\n>>> - a git status in BigProject will say\n>>> \"modified: ../project1 (modified content)\n>>>\n>>> Then I know that I need to update project1 to work with the last version\n>>> M of lib1.\n>>\n>> Maybe no update for project1 is needed, because M only contains a bugfix\n>> which doesn't even need a recompilation of project1. But now you need to\n>> add a commit to project1 nonetheless with a message like \"Updated lib1\n>> with a bugfix which is needed by project2\" which makes your idea of\n>> independent submodules break down.\n> \n> In fact I work ni the world of \"high integrity programming\" then It is\n> just what I need.\n> If there is a bugfix in any library, used by the program it is no more\n> the same program.\n> I need the \"SHA1\" to correspond to the exact and complete source code\n> involved in my executable.\n> \n> And this way the \"SHA1\" of the project sign the \"SHA1\" of the\n> libraries. \n\nI cannot believe you want single commits in your \"Gimp\" repo for every\ncombination of distributions and library versions where someone said\n\"this works\". This is insane and won't scale at all.\n\nWhat you do is that each distribution tests their combination of programs\nand libraries and says \"that works\". And that is why the only sane way to\nrecord this \"high integrity programming\" test result is in the superproject\n(= distribution) and not in each of the program repositories.\n\nI also see that it would be cool when a program could record \"I do work with\nthat library version, if you use another you are on your own\". But it will\nnever say \"I only work with *this* specific library version\", which is what\nyour proposal is trying to do.\n\n>>>> You are opening a can of worms by having two different repos point to the same\n>>>> submodule living in a third repo (which also happens to be their superproject\n>>>> and must somehow ignore it). You'll have two SHA1s for a single submodule;\n>>>> \"git submodule foreach --recursive\" will have interesting results too; and so\n>>>> on. Not good.\n>>>\n>>> As I just said before it is my purpose to do it like that.\n>>\n>> I understood that, but what are you proposing to do to solve all the\n>> problems your approach introduces? You can't just hand wave them away.\n> \n> There is some solutions :\n> \n> - First it is one more **feature** if it does not correspond to your\n> work flow it does not prevent you to work exactly the way you did\n> until now.\n> \n> - Second if you want to use the feature but not want to have the\n> conflict **feature** (for me it is one), just put the independent\n> project with there libs in different directory\n> \n> -+- foo -+- lib1 (in version N)\n> | +- project1\n> |\n> +- bar -+- lib1 (in version M)\n> +- project2\n> \n> - Third if you really need to have project 1 & 2 in the same\n> directory foo, that means they are needed by a third BigProject in\n> the same directory foo depending on project 1 & 2.\n> And then you really need git to declare a conflict.\n\nNo you don't. You just need to git to tell you: this is not the version I\nwas tested against, repeat the tests to be sure.\n\n>>> Let say a concret exemple\n>>>\n>>> 3 different teams work on libtiff, libpng, and libjpeg they are totally\n>>> unrelated.\n>>>\n>>> One more team is working on the \"gimp\". And they need those 3 libs in\n>>> specific versions not necessarily there heads.\n>>>\n>>> One other unrelated team is working on \"gqview\" and need the same libs\n>>> in other specifics versions (Why should they know what te gimp team\n>>> does)\n>>>\n>>> Neither \"gimp\" and \"gqview\" project will contain directory with those\n>>> libs inside. They just depend on them.\n>>>\n>>> And the last team work on the gnome project which need the \"gimp\" and\n>>> \"gqview\". It will be this team witch have to care about having both\n>>> \"gimp\" and \"gqview\" sharing the same libs version>\n>>> And has well the gnome project will not contain \"gqview\" and \"gimp\" in\n>>> its own tree.\n>>> It will also depend on them.\n>>\n>> Cool, that is a real life example resembling what we have a my dayjob. But\n>> a \"gimp\" and \"gqview\" project will only have dependencies like \"use libpng\n>> of version 1.2.3 or newer (because we need a feature/bugfix introduced\n>> there)\" and won't be tied to a special version of that library. This means\n>> they need a dependency like \"SHA1 or newer\" instead of \"exactly this SHA1\".\n> \n> It is useful and simpler to work like this but could introduce some\n> bugs.\n\nBut that model is awfully successful and is used by all distributions I know,\nso I suspect it is not that dangerous (especially when you do your own QA).\n\n> The \"gimp\" team has tested it with libpng 1.2.3 and maybe know that it\n> did not work with previous versions but if they do not have any crystal\n> ball they never know if newer versions will not break something.\n> In fact I doubt that the first version of gimp will work with the last\n> version of libpng.\n\nBut in the real world it is exactly like that: gimp will work with all libpng\n1.2.3 and newer, only when libpng is updated to 2.0.0 you have to check that\nagain. Of course there will be bugs in some combinations. But the advantage of\nbeing able to then only fix libpng and have the bug fixed in Gimp without\nhaving to change it is far greater than the possible problem you are describing\nhere.\n\n>>> It is just the same with aptitude on debian.\n>>> Each package know there dependency by themselves, does not contain there\n>>> dependencies, and do not need a bigger superpackage to tell them what\n>>> are there own dependencies.\n>>\n>> And this is a very good point for the \"version x.yy-z *or newer*\" argument,\n>> they are /never/ tied to the /exact/ x.yy-z version, as that would make the\n>> dependencies pretty much unusable. They use a \"newer than x.yy-z\" scheme.\n> \n> It is an other feature that the one I need.\n> But it is a good idea.\n> \n> Nothing prevent us to make a patch to add a new test in git status to\n> see if the current SHA1 in the libpng repository has the SHA1 of the\n> gitlink in the gimp in its ancestor.\n\nTo make that feature useful for others (e.g. at my dayjob) this would be\nnecessary. And we would never want the exact SHA1 match, even though that\ninformation might be what others (like you) want.\n\n>>> And Still I realy want to have every project knowing there own\n>>> dependency by themselves and not needing an external superproject to\n>>> tell them what they need.\n>>\n>> I want to have that too! I'm just convinced using a gitlink to achieve that\n>> is wrong in so many ways. I'd rather prefer to express such dependencies in\n>> something like a config file, and I believe they should not be as strict as\n>> \"I need exactly that version\" but rather like \"this version or newer (and by\n>> the way: we of course only tested that specific version ;-)\". These\n>> dependencies could then be checked and displayed by git status.\n> \n> It effectively could be in a config file it seem good to me as well.\n\nOk.\n\n> But if git handle this config file.\n> Update it on a \"git add ../libpng && git commit\"\n\nI'm not sure an automatic update at \"git commit\" would be the right thing to\ndo, as I think that should only happen after all tests have run successful,\nnot at the time you commit it. But anyways, that could be done with a post\ncommit hook. Or the test script can do it when it succeeded.\n\n> And control the matching between the project and libraries on\n> \"git status\">\n\nAn extension to \"git status\" to display the dependencies that aren't met is\na valid goal. What about starting with a script (\"git depends\"?) and then see\nwhat can go into status?\n\n> I can not see the difference with a gitlink.\n\nThen you can just use a config file for that, no? ;-)\n"},{"id":"172608","messageId":"20110801221203.GA31614@book.hvoigt.net","threadId":"27708","inReplyTo":"1311932377.3734.182.camel@Naugrim.eriador.com","subject":"Re: tracking submodules out of main directory.","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2011-08-01T22:12:04Z","receivedAt":"2011-08-01T22:12:04Z","isPatch":false,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"Hi,\n\nOn Fri, Jul 29, 2011 at 11:39:37AM +0200, henri GEIST wrote:\n> Let say a concret exemple\n> \n> 3 different teams work on libtiff, libpng, and libjpeg they are totally\n> unrelated.\n> \n> One more team is working on the \"gimp\". And they need those 3 libs in\n> specific versions not necessarily there heads.\n> \n> One other unrelated team is working on \"gqview\" and need the same libs\n> in other specifics versions (Why should they know what te gimp team\n> does)\n> \n> Neither \"gimp\" and \"gqview\" project will contain directory with those\n> libs inside. They just depend on them.\n> \n> And the last team work on the gnome project which need the \"gimp\" and\n> \"gqview\". It will be this team witch have to care about having both\n> \"gimp\" and \"gqview\" sharing the same libs version>\n> And has well the gnome project will not contain \"gqview\" and \"gimp\" in\n> its own tree.\n> It will also depend on them.\n> \n> It is just the same with aptitude on debian.\n> Each package know there dependency by themselves, does not contain there\n> dependencies, and do not need a bigger superpackage to tell them what\n> are there own dependencies.\n\nAs Jens mentioned already in this example you have a\n\n somemodule A needs a version of lib C higher than X\n\tsomemodule B needs a version of lib C higher than Y\n\nrelation. Which in the case of submodules is A points to X and B points\nto Y. Lets assume X is contained in Y. Since only the superproject knows\nabout both A and B its the only instance that can resolve this conflict\nof dependence on C and can choose Y. In your example aptitude would be\nthe superproject containing everything.\n\nThis is actually (simplified) the way submodule merge is implemented. So\nyou see if you want both A and B to use the same version of C you need a\nsuperproject recording this knowledge.\n\nAdding the ability to point to git repositories outside of the worktree\ndoes not solve anything but rather creates more problems. Resolving such\ndependencies can not be achieved if only A knows that it needs version X\nand only B knows that it needs version Y.\n\nCheers Heiko\n"},{"id":"172652","messageId":"1312287584.3261.798.camel@Naugrim.eriador.com","threadId":"27708","inReplyTo":"4E370107.3050002@web.de","subject":"Re: tracking submodules out of main directory.","fromName":"henri GEIST","fromEmail":"henri.geist@flying-robots.com","sentAt":"2011-08-02T12:19:44Z","receivedAt":"2011-08-02T12:19:44Z","isPatch":false,"sender":{"key":"henri.geist@flying-robots.com","avatar":null},"body":"Le lundi 01 août 2011 à 21:39 +0200, Jens Lehmann a écrit :\n> Am 30.07.2011 23:55, schrieb henri GEIST:\n> > Le samedi 30 juillet 2011 à 16:16 +0200, Jens Lehmann a écrit :\n> >> Am 29.07.2011 11:39, schrieb henri GEIST:\n> >>> Le jeudi 28 juillet 2011 à 18:48 +0200, Jens Lehmann a écrit :\n> >>>> Am 28.07.2011 10:57, schrieb henri GEIST:\n> > \n> >> That will then be registered in other git repositories too in your model,\n> >> which gets rid of the \"one file/submodule, one repo\" assumption we now have\n> >> and will introduce ambiguities which are *really* hard to handle.\n> > \n> > I am sorry, I am not a native English speaker. This sentence is to\n> > complex for me. And google translator is of no help in this case.\n> \n> Your proposal of letting multiple gitlinks in different repos point to the\n> same submodule will break the assumption that each file is only handled by\n> a single git repo.\n\nI Agree\n\nThis is not an issue for me but I can understand that it could be for\nsome one else. Even if I do not see why. As it only do it for other git\nrepository that you already now they could have there own autonomous\nlive.\n\n> For example when you have a conflict and do a \"git\n> submodule update --recursive\" in the superproject, the SHA1 used for \"lib\"\n> will depend on the alphabetical order of \"project1\" and \"project2\".\n\nExact.\n\n> And normally after running \"git submodule update --recursive\" you expect all\n> submodules of the superproject to be clean.\n\nNot me. and the next \"git status\" will immediately tell me.\nI do not know about you but \"git status\" is for me a reflex after any\nimportant command.\n\n> But your change breaks this expectation, it will still contain unclean\n> submodule entries even though you just told git it should clean them.\n> What will a \"git submodule sync --recursive\" do when \"project1\" and\n> \"project2\" use different urls in their gitmodules? And so on.\n\nI suspect exactly the same conflict as with \"git submodule update\n--recursive\" or any recursive submodule management.\nBut again if I deliberately chose this model I know what I am doing.\n\n> Commands won't always behave like you expect them to and sometimes will\n> give different results just because different names are used. That's what\n> I meant with ambiguities and that's why I don't think gitlinks are the\n> right method here.\n\nI am sorry. but I do not understand the relation with names.\n\n> > But I agree the step is really weak before enabling to put any regular\n> > file outside of the directory.\n> > I do not see any reasonable workflow (to my eyes) for it but' maybe some\n> > day someone will came with a justifiable workflow which need it. we will\n> > never know.\n> > \n> > But in this case we need solve some questions :\n> > - Will we extend git status signaling untracked files out of the\n> > repository ?\n> \n> I don't think that would work well.\nMe to but it is not me to decide.\n> \n> > - What will do git-clean ? it is already dangerous inside the\n> > repository. and it will be worst if it can access outside of it.\n> \n> Hopefully git clean will learn the --recurse-submodules option in the not\n> too distant future, then you will have just the same danger for the files\n> inside a submodule.\n\nThen this command will be once again more dangerous.\nBut it was before and pepole using it already knows then I suspect it is\nnot worst than before.\n\n> > But they are still confined in an another git repository not\n> > disseminated all over the file system.\n> > And it never corrupt this pointed repository. just ask it to do by it's\n> > own regular git commands.\n> \n> The only difference here is that a submodule can contain more than one file,\n> but you can corrupt those files just as easily as a single file using git\n> commands.\n\nYour right.\n\n> > I can do a second patch to prevent git submodule command to make clones\n> > outside of the repository.\n> > It will requires the user to do those clones manually.\n> > In fact this is already what I do.\n> > My only use of this is to track dependencies.\n> \n> But gitlinks are more than simple dependencies, they are followed! \"git\n> submodule\", status, diff and fetch already follow them. push is learning\n> that right now. checkout, reset, merge and friends are being taught that\n> too (see the enhance_submodule branch in my github repo for the current\n> state). So a gitlink is more than just a simple reference, it is followed\n> by a lot of commands and the submodule it points to is manipulated by\n> those commands. We had a patch for \"git archive --recurse-submodules\" on\n> the list, what will that do when used in \"project1\"?\n\nI think your right. I will make a parallel way not using gitlinks but\nsomething similar which is not followed!\n\n> > In fact I work in the world of \"high integrity programming\" then It is\n> > just what I need.\n> > If there is a bugfix in any library, used by the program it is no more\n> > the same program.\n> > I need the \"SHA1\" to correspond to the exact and complete source code\n> > involved in my executable.\n> > \n> > And this way the \"SHA1\" of the project sign the \"SHA1\" of the\n> > libraries. \n> \n> I cannot believe you want single commits in your \"Gimp\" repo for every\n> combination of distributions and library versions where someone said\n> \"this works\". This is insane and won't scale at all.\n> \n\nThat is exactly what I do. but my team is only 9 people.\nBut we do not make a commit for each possible solution.\nIt. is only when I work on gimp to improve it that I made a commit which\nis update for the ne libpng. but between to commit on the gimp there may\nbu 10 update of libpng an I do not do a commit for each of them only the\nlast stable one.\n\nIt is only on the gnome project that I also need tu update my old\nversion of gqview to work with the libpng used by gimp but as long I do\nnot work on gnome I do not need to synchronize them.\n\nBut I write aircraft autopilot and if I am not at least as strict as\nthat. The certification department of the FAA and EASA will reject my\ncode and my boss will fire me.\n\n> What you do is that each distribution tests their combination of programs\n> and libraries and says \"that works\". And that is why the only sane way to\n> record this \"high integrity programming\" test result is in the superproject\n> (= distribution) and not in each of the program repositories.\n> \n> I also see that it would be cool when a program could record \"I do work with\n> that library version, if you use another you are on your own\". But it will\n> never say \"I only work with *this* specific library version\", which is what\n> your proposal is trying to do.\n\nNo git status only said \"modified: ../libpng (new commits)\"\nFor me modified just mean \"you are on your own\" It do not prevent to\ncompile, execute or do anything else.\n\n> >> I understood that, but what are you proposing to do to solve all the\n> >> problems your approach introduces? You can't just hand wave them away.\n> > \n> > There is some solutions :\n> > \n> > - First it is one more **feature** if it does not correspond to your\n> > work flow it does not prevent you to work exactly the way you did\n> > until now.\n> > \n> > - Second if you want to use the feature but not want to have the\n> > conflict **feature** (for me it is one), just put the independent\n> > project with there libs in different directory\n> > \n> > -+- foo -+- lib1 (in version N)\n> > | +- project1\n> > |\n> > +- bar -+- lib1 (in version M)\n> > +- project2\n> > \n> > - Third if you really need to have project 1 & 2 in the same\n> > directory foo, that means they are needed by a third BigProject in\n> > the same directory foo depending on project 1 & 2.\n> > And then you really need git to declare a conflict.\n> \n> No you don't. You just need to git to tell you: this is not the version I\n> was tested against, repeat the tests to be sure.\n> \n\nThat is just what it will do.\n\n> >> Cool, that is a real life example resembling what we have a my dayjob. But\n> >> a \"gimp\" and \"gqview\" project will only have dependencies like \"use libpng\n> >> of version 1.2.3 or newer (because we need a feature/bugfix introduced\n> >> there)\" and won't be tied to a special version of that library. This means\n> >> they need a dependency like \"SHA1 or newer\" instead of \"exactly this SHA1\".\n> > \n> > It is useful and simpler to work like this but could introduce some\n> > bugs.\n> \n> But that model is awfully successful and is used by all distributions I know,\n> so I suspect it is not that dangerous (especially when you do your own QA).\n> \n\nDepending of how critical is a bug.\nFor an image manipulation programme the ratio effort/needed safety is in\nthe favor of your approche.\n\nBut will you be confident if the nuclear power-plant 50 km from you use\nthis kind of devloppement to contrôle the uranium bars ?\n \nIn any case in my workflow it is not about testing and not seeing\nobvious bugs. It is about having a development process that permit to\nprove there is obviously no bugs. And that model obviously break the\nproof process.\n\n> > The \"gimp\" team has tested it with libpng 1.2.3 and maybe know that it\n> > did not work with previous versions but if they do not have any crystal\n> > ball they never know if newer versions will not break something.\n> > In fact I doubt that the first version of gimp will work with the last\n> > version of libpng.\n> \n> But in the real world it is exactly like that: gimp will work with all libpng\n> 1.2.3 and newer, only when libpng is updated to 2.0.0 you have to check that\n> again. Of course there will be bugs in some combinations. But the advantage of\n> being able to then only fix libpng and have the bug fixed in Gimp without\n> having to change it is far greater than the possible problem you are describing\n> here.\n> \n\nIn this case the commit is not about a change in gimp code, but is a\nstamp to validate the use of gimp with this new version of libpng is\ncertified.\nBut just like in your current use of submodules.\n\n> >>> It is just the same with aptitude on debian.\n> >>> Each package know there dependency by themselves, does not contain there\n> >>> dependencies, and do not need a bigger superpackage to tell them what\n> >>> are there own dependencies.\n> >>\n> >> And this is a very good point for the \"version x.yy-z *or newer*\" argument,\n> >> they are /never/ tied to the /exact/ x.yy-z version, as that would make the\n> >> dependencies pretty much unusable. They use a \"newer than x.yy-z\" scheme.\n> > \n> > It is an other feature that the one I need.\n> > But it is a good idea.\n> > \n> > Nothing prevent us to make a patch to add a new test in git status to\n> > see if the current SHA1 in the libpng repository has the SHA1 of the\n> > gitlink in the gimp in its ancestor.\n> \n> To make that feature useful for others (e.g. at my dayjob) this would be\n> necessary. And we would never want the exact SHA1 match, even though that\n> information might be what others (like you) want.\n> \n\nOk I will do it.\n\n\n> > But if git handle this config file.\n> > Update it on a \"git add ../libpng && git commit\"\n> \n> I'm not sure an automatic update at \"git commit\" would be the right thing to\n> do, as I think that should only happen after all tests have run successful,\n> not at the time you commit it. But anyways, that could be done with a post\n> commit hook. Or the test script can do it when it succeeded.\n> \n\nI am sorry \"make && make test && git add ../libpng && git commit\"\n\n> > And control the matching between the project and libraries on\n> > \"git status\".\n> \n> An extension to \"git status\" to display the dependencies that aren't met is\n> a valid goal. What about starting with a script (\"git depends\"?) and then see\n> what can go into status?\n> \n> > I can not see the difference with a gitlink.\n> \n> Then you can just use a config file for that, no? ;-)\n> \n\nOff corse, I immediately start to work on it.\n\n\tHenri GEIST\n"},{"id":"172653","messageId":"1312289914.3261.836.camel@Naugrim.eriador.com","threadId":"27708","inReplyTo":"20110801221203.GA31614@book.hvoigt.net","subject":"Re: tracking submodules out of main directory.","fromName":"henri GEIST","fromEmail":"henri.geist@flying-robots.com","sentAt":"2011-08-02T12:58:34Z","receivedAt":"2011-08-02T12:58:34Z","isPatch":false,"sender":{"key":"henri.geist@flying-robots.com","avatar":null},"body":"Le mardi 02 août 2011 à 00:12 +0200, Heiko Voigt a écrit :\n> Hi,\n> \n> On Fri, Jul 29, 2011 at 11:39:37AM +0200, henri GEIST wrote:\n> > Let say a concret exemple\n> > \n> > 3 different teams work on libtiff, libpng, and libjpeg they are totally\n> > unrelated.\n> > \n> > One more team is working on the \"gimp\". And they need those 3 libs in\n> > specific versions not necessarily there heads.\n> > \n> > One other unrelated team is working on \"gqview\" and need the same libs\n> > in other specifics versions (Why should they know what te gimp team\n> > does)\n> > \n> > Neither \"gimp\" and \"gqview\" project will contain directory with those\n> > libs inside. They just depend on them.\n> > \n> > And the last team work on the gnome project which need the \"gimp\" and\n> > \"gqview\". It will be this team witch have to care about having both\n> > \"gimp\" and \"gqview\" sharing the same libs version>\n> > And has well the gnome project will not contain \"gqview\" and \"gimp\" in\n> > its own tree.\n> > It will also depend on them.\n> > \n> > It is just the same with aptitude on debian.\n> > Each package know there dependency by themselves, does not contain there\n> > dependencies, and do not need a bigger superpackage to tell them what\n> > are there own dependencies.\n> \n> As Jens mentioned already in this example you have a\n> \n> somemodule A needs a version of lib C higher than X\n> \tsomemodule B needs a version of lib C higher than Y\n> \n> relation. Which in the case of submodules is A points to X and B points\n> to Y. Lets assume X is contained in Y. Since only the superproject knows\n> about both A and B its the only instance that can resolve this conflict\n> of dependence on C and can choose Y. In your example aptitude would be\n> the superproject containing everything.\n> \n\nI do not want to have a superproject. just as with aptitude. Each\npackage store its own dependencies itself.\nI do not want to need a super package who now every dependencies of\nevery possible packages.\nFirst because it is impractical to maintain an exhaustive list of all\npossible packages (including unofficial ones.)\nSecondly because I have no need for this and it will require somme more\nworks.\nThird for different people witch use and share there own subset off\nunofficial package they needs to cook a specific super package for each\nunique case.\n\n> This is actually (simplified) the way submodule merge is implemented. So\n> you see if you want both A and B to use the same version of C you need a\n> superproject recording this knowledge.\n\nAnd tha is my problem.\n\n> Adding the ability to point to git repositories outside of the worktree\n> does not solve anything but rather creates more problems. Resolving such\n> dependencies can not be achieved if only A knows that it needs version X\n> and only B knows that it needs version Y.\n> \n\nWhy not it work perfect for me and for debian as well.\nYes I now for speed purpose they scans all the package header and store\ntheir dependency requirement in a database. but it is only for speed and\nit is automatic generated by the info \"In the packages them selves\". I\ndo not think they ever edit it by hand to define the dependency in the\nDB.\n\nIn fact I suppose this by what I seen by using it I never looked in the\napt source code.\n\n\tHenri GEIST\n"},{"id":"172683","messageId":"4E384510.1070803@web.de","threadId":"27708","inReplyTo":"1312287584.3261.798.camel@Naugrim.eriador.com","subject":"Re: tracking submodules out of main directory.","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-08-02T18:42:24Z","receivedAt":"2011-08-02T18:42:24Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 02.08.2011 14:19, schrieb henri GEIST:\n> Le lundi 01 août 2011 à 21:39 +0200, Jens Lehmann a écrit :\n>> Am 30.07.2011 23:55, schrieb henri GEIST:\n>>> I can not see the difference with a gitlink.\n>>\n>> Then you can just use a config file for that, no? ;-)\n> \n> Off corse, I immediately start to work on it.\n\nI'm looking forward to that!\n"},{"id":"172733","messageId":"20110803062536.GB33203@book.hvoigt.net","threadId":"27708","inReplyTo":"4E384510.1070803@web.de","subject":"Re: tracking submodules out of main directory.","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2011-08-03T06:25:39Z","receivedAt":"2011-08-03T06:25:39Z","isPatch":false,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"Hi Henri,\n\nOn Tue, Aug 02, 2011 at 08:42:24PM +0200, Jens Lehmann wrote:\n> Am 02.08.2011 14:19, schrieb henri GEIST:\n> > Le lundi 01 ao??t 2011 ?? 21:39 +0200, Jens Lehmann a ??crit :\n> >> Am 30.07.2011 23:55, schrieb henri GEIST:\n> >>> I can not see the difference with a gitlink.\n> >>\n> >> Then you can just use a config file for that, no? ;-)\n> > \n> > Off corse, I immediately start to work on it.\n> \n> I'm looking forward to that!\n\nBefore hacking away please share some design information about this.\n\nAnother thing:\n\nIt sounds like the workflow you want to achieve is similar to the one\nthe android developers are using. They have a lot of submodules which\nneed automatic updating.\n\nThe last time I checked they used repo (similar tool to submodules)\ntogether with gerrit.\n\nAFAIR they wanted to switch to submodules and have gerrit automatically\nmake the superproject commits for single submodule changes. Additionally\nif a change involves multiple submodules the developer should be able to\ntie them together using a superproject commit.\n\nHave a look over there whether that workflow might help you?\n\nCheers Heiko\n"},{"id":"172736","messageId":"1312362448.3261.861.camel@Naugrim.eriador.com","threadId":"27708","inReplyTo":"CAJsNXT=93FHjbi42JKA3Pg7PGXs0kEONJ5AC5SSPpa5RSVqB=A@mail.gmail.com","subject":"Re: tracking submodules out of main directory.","fromName":"henri GEIST","fromEmail":"henri.geist@flying-robots.com","sentAt":"2011-08-03T09:07:28Z","receivedAt":"2011-08-03T09:07:28Z","isPatch":false,"sender":{"key":"henri.geist@flying-robots.com","avatar":null},"body":"Le mardi 02 août 2011 à 12:19 -0700, PJ Weisberg a écrit :\n> On Tuesday, August 2, 2011, henri GEIST\n> wrote:\n> > Le mardi 02 août 2011 à 00:12 +0200, Heiko Voigt a écrit :\n> >> Adding the ability to point to git repositories outside of the\n> worktree\n> >> does not solve anything but rather creates more problems. Resolving\n> such\n> >> dependencies can not be achieved if only A knows that it needs\n> version X\n> >> and only B knows that it needs version Y.\n> >>\n> >\n> > Why not it work perfect for me and for debian as well.\n> \n> In the Debian analogy: A knows that it needs version X, B knows that\n> it needs version Y, but A does not know that if it installs version X,\n> B will break. That's the job of the superproject (Aptitude).\n> \n\nYour right.\n"},{"id":"172750","messageId":"1312374382.3261.913.camel@Naugrim.eriador.com","threadId":"27708","inReplyTo":"20110803062536.GB33203@book.hvoigt.net","subject":"Re: tracking submodules out of main directory.","fromName":"henri GEIST","fromEmail":"henri.geist@flying-robots.com","sentAt":"2011-08-03T12:26:22Z","receivedAt":"2011-08-03T12:26:22Z","isPatch":false,"sender":{"key":"henri.geist@flying-robots.com","avatar":null},"body":"Le mercredi 03 août 2011 à 08:25 +0200, Heiko Voigt a écrit :\n> Hi Henri,\n> \n> On Tue, Aug 02, 2011 at 08:42:24PM +0200, Jens Lehmann wrote:\n> > Am 02.08.2011 14:19, schrieb henri GEIST:\n> > > Le lundi 01 ao??t 2011 ?? 21:39 +0200, Jens Lehmann a ??crit :\n> > >> Am 30.07.2011 23:55, schrieb henri GEIST:\n> > >>> I can not see the difference with a gitlink.\n> > >>\n> > >> Then you can just use a config file for that, no? ;-)\n> > > \n> > > Off corse, I immediately start to work on it.\n> > \n> > I'm looking forward to that!\n> \n> Before hacking away please share some design information about this.\n> \n\nOk this is what I intend to do.\n\nI plan to use a config file containing lines like\n\n\"path_to_poited_repo SHA1_of_intended_commit URL_of_origin\"\n\nthe URL part will not be required.\n\nthis file will be a list of pointer to other project.\n\nI have plane to name the file \".gitdependencies\" and put it at the root\nof the current repository.\n\n\nThen I will :\n\n1) Adding to git-status the ability to scan this file and report :\n - if the repository pointed by the path does not exist\n - if the SHA1 of the current checkout of this repository mismatch.\n - if this repository content differ from its checkout.\n\n2) Adding to git status the ability to say if the current checkout has\n the expected one in its ancestors.\n\n3) Adding to git-add the ability to:\n - create/update this file when trying to add an external repository\n - giving up if it is not an external repository.\n - automatically add the dependency file as well.\n\n4) Adding to git-rm the ability to:\n - remove lines in this file.\n - add the result to index.\n - maybe removing the complete file if it is empty.\n\n5) Adding to git-reset the ability to:\n - reset those lines one by one.\n - adding the the file to the index.\n\nI think I will do those steps as separate commits because they can works\nindependently. it just need you to do the unimplemented step manually\nuntil it is done.\n\nThat is a first proposal, all your comment will be appreciate.\n\n> Another thing:\n> \n> It sounds like the workflow you want to achieve is similar to the one\n> the android developers are using. They have a lot of submodules which\n> need automatic updating.\n> \n> The last time I checked they used repo (similar tool to submodules)\n> together with gerrit.\n> \n> AFAIR they wanted to switch to submodules and have gerrit automatically\n> make the superproject commits for single submodule changes. Additionally\n> if a change involves multiple submodules the developer should be able to\n> tie them together using a superproject commit.\n> \n> Have a look over there whether that workflow might help you?\n\nI just add a quick look on the android web site and I did not understand\nwhat exactly repo do.\n\nAll there documentation only say how to install it and checkout android\nbut it dose not explain anything about repo itself.\n\nI will search more info about it.\n\n\tHenri GEIST\n"},{"id":"172783","messageId":"7v8vractdw.fsf@alter.siamese.dyndns.org","threadId":"27708","inReplyTo":"1312374382.3261.913.camel@Naugrim.eriador.com","subject":"Re: tracking submodules out of main directory.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-08-03T17:11:23Z","receivedAt":"2011-08-03T17:11:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"henri GEIST writes:\n\n> I plan to use a config file containing lines like\n>\n> \"path_to_poited_repo SHA1_of_intended_commit URL_of_origin\"\n>\n> the URL part will not be required.\n>\n> this file will be a list of pointer to other project.\n\nI wasn't paying attention to this thread, but I have to ask \"why\" here.\n\nThe first two are what gitlink was designed to do in the superproject that\nties multiple submodules together, and the last one is also supplied by\nthe .gitmodules in that superproject. This seems to be adding the same\ninformation in a redundant way by saying \"this version A0 of submodule A\nwants version B0 of submodule B and version C0 of submodule C\" when the\nsupermodule can say \"the consistent view I record is to have version A0,\nB0 and C0 of submodules A, B and C, respectively\".\n\nI also suspect that allowing each submodule to know and demand specific\nversions of other submodules will lead to inconsistencies. Which version\nof submodule C would you demand to have when submodule A wants version C0\nand submodule B wants version C1 of it?\n"},{"id":"172794","messageId":"4E399C62.30604@web.de","threadId":"27708","inReplyTo":"7v8vractdw.fsf@alter.siamese.dyndns.org","subject":"Re: tracking submodules out of main directory.","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-08-03T19:07:14Z","receivedAt":"2011-08-03T19:07:14Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 03.08.2011 19:11, schrieb Junio C Hamano:\n> henri GEIST writes:\n> \n>> I plan to use a config file containing lines like\n>>\n>> \"path_to_poited_repo SHA1_of_intended_commit URL_of_origin\"\n>>\n>> the URL part will not be required.\n>>\n>> this file will be a list of pointer to other project.\n> \n> I wasn't paying attention to this thread, but I have to ask \"why\" here.\n> \n> The first two are what gitlink was designed to do in the superproject that\n> ties multiple submodules together, and the last one is also supplied by\n> the .gitmodules in that superproject. This seems to be adding the same\n> information in a redundant way by saying \"this version A0 of submodule A\n> wants version B0 of submodule B and version C0 of submodule C\" when the\n> supermodule can say \"the consistent view I record is to have version A0,\n> B0 and C0 of submodules A, B and C, respectively\".\n\nDuring the discussion this evolved from a simple \"I need that submodule\nwith exactly this version\" to something I believe is more generic and\nvery useful for others. As I see it now a submodule should be able to say:\n\n1) To use me, you need another submodule \"foo\"\n\n This is very helpful when you want to add the Gimp submodule and it\n can tell you you'll need the libpng submodule too in your superproject\n (but I'd vote to use the submodule name here, not the path as that\n should be the superproject's decision).\n\nIn addition to that, it can (but mustn't) specify any of the following:\n\na) Of this submodule \"foo\" I need at least that version because I won't\n compile/work with older versions of that. (this can be tightened to\n \"exactly that version\" to give henri the behavior he wants, but that\n should be policy, not mandatory)\n\n Gimp could say it needs at least libpng 012345 because in that version\n the function foobar() was added it now depends on. Normally this won't\n be updated very often, but if people like henri use that to say \"I'll\n only promise to work well with that exact version, as that went through\n extensive QA\" they might change that on virtually every commit.\n\nb) And if you don't know where to get it, use this url\n\n That can give the superproject a hint where it can clone that\n repository from. That could be helpful for distributions to sort out\n the dependencies of the packages they pull in.\n\nThat is all stuff the submodule knows better than the superproject. And\nthat information can be used to *inform* the user about the submodule's\nneeds, maybe using \"git status --submodule-dependencies\" will print:\n\n# submodule \"Gimp\" requests a libpng 567890 or newer\n# submodule \"foo\" has missing dependency \"bar\"\n\nBut the user can choose to ignore that (because he knows he has the png\nsupport disabled and he doesn't need the fancy help files from bar).\n\nAnd maybe \"git submodule add\" learns an option to automatically add all\nthe other submodules the new one depends on too (for that we would need\nthe url).\n\nBut the superproject is still the place to say: I know these versions of\nall submodules work together, so I commit their gitlinks here. But this\nscheme enables submodules to give hints to help the superproject's user.\n\n> I also suspect that allowing each submodule to know and demand specific\n> versions of other submodules will lead to inconsistencies. Which version\n> of submodule C would you demand to have when submodule A wants version C0\n> and submodule B wants version C1 of it?\n\nRight, in the discussion so far it seemed like henri seems to be the only\nuser who is wanting an exact match, and he says he needs to see these\ninconsistencies. But I think he can modify the \"version xxx or newer\" to\nhis needs without imposing these inconsistencies on users (like me) who\ndon't want to see them.\n"},{"id":"172799","messageId":"7vaabqb7vf.fsf@alter.siamese.dyndns.org","threadId":"27708","inReplyTo":"4E399C62.30604@web.de","subject":"Re: tracking submodules out of main directory.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-08-03T19:41:24Z","receivedAt":"2011-08-03T19:41:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jens Lehmann writes:\n\n> 1) To use me, you need another submodule \"foo\"\n>\n> This is very helpful when you want to add the Gimp submodule and it\n> can tell you you'll need the libpng submodule too in your superproject\n> (but I'd vote to use the submodule name here, not the path as that\n> should be the superproject's decision).\n\nThat is something you can add to .gitmodules in the superproject, no?\nE.g.\n\n\t[submodule \"Gimp\"]\n \turl = http://some/where/\n\t\tpath = gimp/\n \tdepends = version 1.2.3 of \"Glib\"\n\n\t[submodule \"Glib\"]\n \turl = http://some/where/else/\n\t\tpath = libs/glib\n\n> In addition to that, it can (but mustn't) specify any of the following:\n\nI am guessing you meant \"does not have to\", instead of mustn't, here...\n\n> a) Of this submodule \"foo\" I need at least that version because I won't\n> compile/work with older versions of that. (this can be tightened to\n> \"exactly that version\" to give henri the behavior he wants, but that\n> should be policy, not mandatory)\n\nThe \"loose collection of projects\" approach like that has its uses, and it\nis called \"repo\". Why re-invent it? The behaviour Henri wants to specify\nthe exact version is how git submodules work already, so I do not see\nthere is anything to be done here.\n\n> b) And if you don't know where to get it, use this url\n\nAgain that is the job of .gitmodules in the superproject.\n\n> That is all stuff the submodule knows better than the superproject.\n\nNot necessarily. The version A0 of submodule A may depend on submodule B\nand may also know it must have at least version B0 of that submodule, but\nthe superproject would know other constraints, e.g. the superproject\nitself also calls into submodule B and wants a newer version B1 of it.\n"},{"id":"172804","messageId":"1312405480.3261.957.camel@Naugrim.eriador.com","threadId":"27708","inReplyTo":"7v8vractdw.fsf@alter.siamese.dyndns.org","subject":"Re: tracking submodules out of main directory.","fromName":"henri GEIST","fromEmail":"henri.geist@flying-robots.com","sentAt":"2011-08-03T21:04:40Z","receivedAt":"2011-08-03T21:04:40Z","isPatch":false,"sender":{"key":"henri.geist@flying-robots.com","avatar":null},"body":"Le mercredi 03 août 2011 à 10:11 -0700, Junio C Hamano a écrit :\n> henri GEIST writes:\n> \n> > I plan to use a config file containing lines like\n> >\n> > \"path_to_poited_repo SHA1_of_intended_commit URL_of_origin\"\n> >\n> > the URL part will not be required.\n> >\n> > this file will be a list of pointer to other project.\n> \n> I wasn't paying attention to this thread, but I have to ask \"why\" here.\n> \n> The first two are what gitlink was designed to do in the superproject that\n> ties multiple submodules together, and the last one is also supplied by\n> the .gitmodules in that superproject.\n\nYes my only problem is that it is forbidden to put a submodule outside\nof the repository.\nThat is way I had done a patch witch enable me to do so and I use it\nflawlessly every day. with total satisfaction.\n\n> This seems to be adding the same information in a redundant way by saying\n> \"this version A0 of submodule A wants version B0 of submodule B and\n> version C0 of submodule C\" when the supermodule can say \"the consistent\n> view I record is to have version A0, B0 and C0 of submodules A, B and C,\n> respectively\".\n> \n\nExact but my goal is to get ride of the superproject.\nThis is how I will remove the redondency.\nCause creating a projet just to said to other project what they need is\na wast. Each project has to now by itself what it need.\n\nAnd each user will have his own list of project to work on.\nThen they we will create one different superproject for each user.\n\nOne user can work on a superproject containing :\ngimp, gqview, libpng\n\nOne other will work on a superproject containing :\ngimp, gphoto, libpng, libusb\n\nThe next one will work on a superproject containing :\nxsane, libusb\n\nThey can absolutely not share there superproject only the normal\nprojects.\nAnd if the dependency are defined in superproject, and not in the\nprojects themselves. Users can not share their dependency constructs.\n\nI have no intend to have \"sub\"modules but to have generic modules with\nno hierarchies only dependence relations. Which could even be crossed.\n(Module A require module B and module B require module A.)\nEven if in this particular case I do not see the point to make two\ndistinct modules.\n\n\n> I also suspect that allowing each submodule to know and demand specific\n> versions of other submodules will lead to inconsistencies. Which version\n> of submodule C would you demand to have when submodule A wants version C0\n> and submodule B wants version C1 of it?\n> \n\nThat is already the case with normal submodules.\nAnd of corse if you have a project which recursively depend of to\nversion of the same library, you need to update it, and it has nothing\nto do with git. Git will just make it obvious.\n\n\nThe reason we decide to make a parallel file \".gitdependencies\",\ncontaining something really similar to the content of \".gitmodules\"\nis that in .gitdependencies we will put references outside of repository\nand in \".gitmodules\" the references inside git repository as actual.\n\nThis separation will be done because Jens Lehmann show us\nthat .gitmodules are lot more that what I expected from those reference\nand do not think that the others abilities of submodules should apply to\nexternal modules.\n\n\tHenri\n"},{"id":"172806","messageId":"4E39BDFF.3050804@web.de","threadId":"27708","inReplyTo":"7vaabqb7vf.fsf@alter.siamese.dyndns.org","subject":"Re: tracking submodules out of main directory.","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-08-03T21:30:39Z","receivedAt":"2011-08-03T21:30:39Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 03.08.2011 21:41, schrieb Junio C Hamano:\n> Jens Lehmann writes:\n> \n>> 1) To use me, you need another submodule \"foo\"\n>>\n>> This is very helpful when you want to add the Gimp submodule and it\n>> can tell you you'll need the libpng submodule too in your superproject\n>> (but I'd vote to use the submodule name here, not the path as that\n>> should be the superproject's decision).\n> \n> That is something you can add to .gitmodules in the superproject, no?\n> E.g.\n> \n> \t[submodule \"Gimp\"]\n> \turl = http://some/where/\n> \t\tpath = gimp/\n> \tdepends = version 1.2.3 of \"Glib\"\n> \n> \t[submodule \"Glib\"]\n> \turl = http://some/where/else/\n> \t\tpath = libs/glib\n\nThe \"depends\" information is not very useful inside the superproject,\nbecause when you already know that there you can simply commit version\n1.2.3 of Glib together with Gimp instead of adding that information.\nThat's what gitlinks are for, no?\n\nBut when you fetch a new version of Gimp into your submodule, it would be\nreally nice if the superproject could be notified that the Gimp developers\nupdated to 1.2.4 of Glib and inform you that an update of Glib might be\nappropriate. That could avoid having you to dig through compiler errors to\nfind out that the new foobar() function from Glib 1.2.4 is needed (and if\nyou need to pull in a bugfix in Glib, you might notice that *a lot* later\nwhen you forget to do that).\n\n>> In addition to that, it can (but mustn't) specify any of the following:\n> \n> I am guessing you meant \"does not have to\", instead of mustn't, here...\n\nSure, thanks for deciphering that.\n\n>> a) Of this submodule \"foo\" I need at least that version because I won't\n>> compile/work with older versions of that. (this can be tightened to\n>> \"exactly that version\" to give henri the behavior he wants, but that\n>> should be policy, not mandatory)\n> \n> The \"loose collection of projects\" approach like that has its uses, and it\n> is called \"repo\". Why re-invent it? The behaviour Henri wants to specify\n> the exact version is how git submodules work already, so I do not see\n> there is anything to be done here.\n\nLet me make this clear: this is not about changing how submodules are\ncommitted in a superproject. It is not about having a loose collection of\nprojects, they stay tied together in a defined state by the superproject.\n\nHenri wanted it a bit upside down: any submodule could request a certain\nversion of another submodule somewhere else in the repo. And he wanted to\nuse gitlinks from one submodule to another for that, which I - hopefully -\nconvinced him was no good idea.\n\nBut I understand his need to have some kind of \"version hint\" from one\nsubmodule to another. Just that he wants to take the hint very serious,\nwhile I see it as means to communicate from the submodule maintainer to\nthe superproject developers that another submodule might have to be\nupdated too when they do that to his.\n\n>> b) And if you don't know where to get it, use this url\n> \n> Again that is the job of .gitmodules in the superproject.\n\nYes. But this idea is about how the url could get into the .gitmodules of\nthe superproject in the first place. That can make it easier for the\nsuperproject's developer to import a submodule into his repo and much more\nimportant: it makes it possible to pull in submodule dependencies\nautomatically e.g. when running \"git submodule add --resolve-dependencies\nGimp\".\n\n>> That is all stuff the submodule knows better than the superproject.\n> \n> Not necessarily. The version A0 of submodule A may depend on submodule B\n> and may also know it must have at least version B0 of that submodule, but\n> the superproject would know other constraints, e.g. the superproject\n> itself also calls into submodule B and wants a newer version B1 of it.\n\nRight. That's what I tried to explain to Henri, the superproject ties it all\ntogether. But I also like his idea to add a way to communicate information\nfrom the submodule to the superproject, and give the superproject a choice\nif it wants to use it.\n"},{"id":"172812","messageId":"20110803214530.GA34347@book.hvoigt.net","threadId":"27708","inReplyTo":"4E399C62.30604@web.de","subject":"Re: tracking submodules out of main directory.","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2011-08-03T21:45:58Z","receivedAt":"2011-08-03T21:45:58Z","isPatch":false,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"Hi,\n\nOn Wed, Aug 03, 2011 at 09:07:14PM +0200, Jens Lehmann wrote:\n> Am 03.08.2011 19:11, schrieb Junio C Hamano:\n> But the superproject is still the place to say: I know these versions of\n> all submodules work together, so I commit their gitlinks here. But this\n> scheme enables submodules to give hints to help the superproject's user.\n> \n> > I also suspect that allowing each submodule to know and demand specific\n> > versions of other submodules will lead to inconsistencies. Which version\n> > of submodule C would you demand to have when submodule A wants version C0\n> > and submodule B wants version C1 of it?\n> \n> Right, in the discussion so far it seemed like henri seems to be the only\n> user who is wanting an exact match, and he says he needs to see these\n> inconsistencies. But I think he can modify the \"version xxx or newer\" to\n> his needs without imposing these inconsistencies on users (like me) who\n> don't want to see them.\n\nAnd I imagine if a submodule has such hints we could add a command say\n\n\tgit submodule resolve-dependencies\n\nwhich could resolve such \"I need a version newer than\" hints given by a\nsubmodule to help the user to update a submodule in the superproject.\n\nDisclaimer: I think we need to think about all the implications such a\nscheme introduces very carefully. The picture is still a bit blurry for\nme.\n\nCheers Heiko\n"},{"id":"172813","messageId":"1312408175.3261.998.camel@Naugrim.eriador.com","threadId":"27708","inReplyTo":"4E399C62.30604@web.de","subject":"Re: tracking submodules out of main directory.","fromName":"henri GEIST","fromEmail":"henri.geist@flying-robots.com","sentAt":"2011-08-03T21:49:35Z","receivedAt":"2011-08-03T21:49:35Z","isPatch":false,"sender":{"key":"henri.geist@flying-robots.com","avatar":null},"body":"Le mercredi 03 août 2011 à 21:07 +0200, Jens Lehmann a écrit :\n> Am 03.08.2011 19:11, schrieb Junio C Hamano:\n> > henri GEIST writes:\n> > \n> >> I plan to use a config file containing lines like\n> >>\n> >> \"path_to_poited_repo SHA1_of_intended_commit URL_of_origin\"\n> >>\n> >> the URL part will not be required.\n> >>\n> >> this file will be a list of pointer to other project.\n> > \n> > I wasn't paying attention to this thread, but I have to ask \"why\" here.\n> > \n> > The first two are what gitlink was designed to do in the superproject that\n> > ties multiple submodules together, and the last one is also supplied by\n> > the .gitmodules in that superproject. This seems to be adding the same\n> > information in a redundant way by saying \"this version A0 of submodule A\n> > wants version B0 of submodule B and version C0 of submodule C\" when the\n> > supermodule can say \"the consistent view I record is to have version A0,\n> > B0 and C0 of submodules A, B and C, respectively\".\n> \n> During the discussion this evolved from a simple \"I need that submodule\n> with exactly this version\" to something I believe is more generic and\n> very useful for others. As I see it now a submodule should be able to say:\n> \n> 1) To use me, you need another submodule \"foo\"\n> \n> This is very helpful when you want to add the Gimp submodule and it\n> can tell you you'll need the libpng submodule too in your superproject\n> (but I'd vote to use the submodule name here, not the path as that\n> should be the superproject's decision).\n> \n> In addition to that, it can (but mustn't) specify any of the following:\n> \n> a) Of this submodule \"foo\" I need at least that version because I won't\n> compile/work with older versions of that. (this can be tightened to\n> \"exactly that version\" to give henri the behavior he wants, but that\n> should be policy, not mandatory)\n> \n\nOf corse and git will not enforce this policy.\nGit status will only say the version is unrelated, match or is higher.\nAnd it is left to the human reading the status to decide if it is OK\nwith his policy.\n\n> Gimp could say it needs at least libpng 012345 because in that version\n> the function foobar() was added it now depends on. Normally this won't\n> be updated very often, but if people like henri use that to say \"I'll\n> only promise to work well with that exact version, as that went through\n> extensive QA\" they might change that on virtually every commit.\n> \n\nIn fact I do so very rarely I do not update my project to track the last\nversion of the library until the project need it. If the library get new\nfeatures and improvement that I do not need I keep the old version.\nI will not rewrite the tones of certification papers to certify the use\nof the new library version without needs. It will destroy all the\nforests.\n\n> b) And if you don't know where to get it, use this url\n> \n> That can give the superproject a hint where it can clone that\n> repository from. That could be helpful for distributions to sort out\n> the dependencies of the packages they pull in.\n> \n> That is all stuff the submodule knows better than the superproject. And\n> that information can be used to *inform* the user about the submodule's\n> needs, maybe using \"git status --submodule-dependencies\" will print:\n> \n> # submodule \"Gimp\" requests a libpng 567890 or newer\n> # submodule \"foo\" has missing dependency \"bar\"\n\n> But the user can choose to ignore that (because he knows he has the png\n> support disabled and he doesn't need the fancy help files from bar).\n> \n> And maybe \"git submodule add\" learns an option to automatically add all\n> the other submodules the new one depends on too (for that we would need\n> the url).\n> \n\nProvided that you use a superproject. But my goal is to eliminate it.\n\n> But the superproject is still the place to say: I know these versions of\n> all submodules work together, so I commit their gitlinks here. But this\n> scheme enables submodules to give hints to help the superproject's user.\n> \n\nor they can do it by them selves has now they have all the needed infos.\n\n> > I also suspect that allowing each submodule to know and demand specific\n> > versions of other submodules will lead to inconsistencies. Which version\n> > of submodule C would you demand to have when submodule A wants version C0\n> > and submodule B wants version C1 of it?\n> \n> Right, in the discussion so far it seemed like henri seems to be the only\n> user who is wanting an exact match, and he says he needs to see these\n> inconsistencies.\n\nI suspect I am just the only one you now about.\nBecause that is just what actual submodules does, and nobody complain.\n\nIf you\n - cd into one of your submodules\n - make a commit\n - go back into the main repository\n - make git status\nIt will tell you :\n\"modified: the_submodule_name/ (new commits)\"\n\nNote it actually will say \"new commits\" even if it is older or totally\nunrelated. It just signal a mismatch.\nThen what I need on this point is just what it actually do.\n\n> But I think he can modify the \"version xxx or newer\" to\n> his needs without imposing these inconsistencies on users (like me) who\n> don't want to see them.\n> \n\nOf corse git status has never imposed anything.\n\nBut I will enabling it to make the distinction between unmatched and\nnewer version.\n\n\tHenri\n"},{"id":"172824","messageId":"1312410562.3261.1030.camel@Naugrim.eriador.com","threadId":"27708","inReplyTo":"4E39BDFF.3050804@web.de","subject":"Re: tracking submodules out of main directory.","fromName":"henri GEIST","fromEmail":"henri.geist@flying-robots.com","sentAt":"2011-08-03T22:29:22Z","receivedAt":"2011-08-03T22:29:22Z","isPatch":false,"sender":{"key":"henri.geist@flying-robots.com","avatar":null},"body":"Le mercredi 03 août 2011 à 23:30 +0200, Jens Lehmann a écrit :\n> Am 03.08.2011 21:41, schrieb Junio C Hamano:\n> > Jens Lehmann writes:\n> > \n> >> 1) To use me, you need another submodule \"foo\"\n> >>\n> >> This is very helpful when you want to add the Gimp submodule and it\n> >> can tell you you'll need the libpng submodule too in your superproject\n> >> (but I'd vote to use the submodule name here, not the path as that\n> >> should be the superproject's decision).\n> > \n> > That is something you can add to .gitmodules in the superproject, no?\n> > E.g.\n> > \n> > \t[submodule \"Gimp\"]\n> > \turl = http://some/where/\n> > \t\tpath = gimp/\n> > \tdepends = version 1.2.3 of \"Glib\"\n> > \n> > \t[submodule \"Glib\"]\n> > \turl = http://some/where/else/\n> > \t\tpath = libs/glib\n> \n> The \"depends\" information is not very useful inside the superproject,\n> because when you already know that there you can simply commit version\n> 1.2.3 of Glib together with Gimp instead of adding that information.\n> That's what gitlinks are for, no?\n> \n> But when you fetch a new version of Gimp into your submodule, it would be\n> really nice if the superproject could be notified that the Gimp developers\n> updated to 1.2.4 of Glib and inform you that an update of Glib might be\n> appropriate. That could avoid having you to dig through compiler errors to\n> find out that the new foobar() function from Glib 1.2.4 is needed (and if\n> you need to pull in a bugfix in Glib, you might notice that *a lot* later\n> when you forget to do that).\n> \n\nExact, I am really happy to read this.\nAnd better do not bother to have the suproject.\ncd to gimp directory, type git status it can tell you every thing and\nwhen your satisfied you just have to type make.\nAt this point the superproject have not any use. \n\n> >> In addition to that, it can (but mustn't) specify any of the following:\n> > \n> > I am guessing you meant \"does not have to\", instead of mustn't, here...\n> \n> Sure, thanks for deciphering that.\n> \n> >> a) Of this submodule \"foo\" I need at least that version because I won't\n> >> compile/work with older versions of that. (this can be tightened to\n> >> \"exactly that version\" to give henri the behavior he wants, but that\n> >> should be policy, not mandatory)\n> > \n> > The \"loose collection of projects\" approach like that has its uses, and it\n> > is called \"repo\". Why re-invent it? The behaviour Henri wants to specify\n> > the exact version is how git submodules work already, so I do not see\n> > there is anything to be done here.\n> \n> Let me make this clear: this is not about changing how submodules are\n> committed in a superproject. It is not about having a loose collection of\n> projects, they stay tied together in a defined state by the superproject.\n> \n\nYes but for me, from when I started this this topic, it was all about\nhaving a loose collection of project with dependency references between\nthem. And get rid of the superproject.\nIt is my first and only goal.\n\n> Henri wanted it a bit upside down: any submodule could request a certain\n> version of another submodule somewhere else in the repo. And he wanted to\n> use gitlinks from one submodule to another for that, which I - hopefully -\n> convinced him was no good idea.\n> \n\nYou just convince me that submodules are more than I need and to make a\nlighter independent version of submodules which will never been followed\nby git commands.\n\n> But I understand his need to have some kind of \"version hint\" from one\n> submodule to another. Just that he wants to take the hint very serious,\n> while I see it as means to communicate from the submodule maintainer to\n> the superproject developers that another submodule might have to be\n> updated too when they do that to his.\n> \n\nYes\n\n> >> b) And if you don't know where to get it, use this url\n> > \n> > Again that is the job of .gitmodules in the superproject.\n> \n> Yes. But this idea is about how the url could get into the .gitmodules of\n> the superproject in the first place. That can make it easier for the\n> superproject's developer to import a submodule into his repo and much more\n> important: it makes it possible to pull in submodule dependencies\n> automatically e.g. when running \"git submodule add --resolve-dependencies\n> Gimp\".\n\nOnly if you have a superproject.\nIf not do the same thing from the gimp repository, now it contain all\nnecessary infos to do the job.\n\n> >> That is all stuff the submodule knows better than the superproject.\n> > \n> > Not necessarily. The version A0 of submodule A may depend on submodule B\n> > and may also know it must have at least version B0 of that submodule, but\n> > the superproject would know other constraints, e.g. the superproject\n> > itself also calls into submodule B and wants a newer version B1 of it.\n> \n> Right. That's what I tried to explain to Henri, the superproject ties it all\n> together. But I also like his idea to add a way to communicate information\n> from the submodule to the superproject, and give the superproject a choice\n> if it wants to use it.\n> \n\nyes but the superproject contain no code in your design.\nThen it will never need anything by itself.\nIt is only a container which you will inform with data already known by\nthe submodules I do not see any value to it.\n\n\tHenri\n"},{"id":"172827","messageId":"1312411298.3261.1041.camel@Naugrim.eriador.com","threadId":"27708","inReplyTo":"20110803214530.GA34347@book.hvoigt.net","subject":"Re: tracking submodules out of main directory.","fromName":"henri GEIST","fromEmail":"henri.geist@flying-robots.com","sentAt":"2011-08-03T22:41:38Z","receivedAt":"2011-08-03T22:41:38Z","isPatch":false,"sender":{"key":"henri.geist@flying-robots.com","avatar":null},"body":"Le mercredi 03 août 2011 à 23:45 +0200, Heiko Voigt a écrit :\n> Hi,\n> \n> On Wed, Aug 03, 2011 at 09:07:14PM +0200, Jens Lehmann wrote:\n> > Am 03.08.2011 19:11, schrieb Junio C Hamano:\n> > But the superproject is still the place to say: I know these versions of\n> > all submodules work together, so I commit their gitlinks here. But this\n> > scheme enables submodules to give hints to help the superproject's user.\n> > \n> > > I also suspect that allowing each submodule to know and demand specific\n> > > versions of other submodules will lead to inconsistencies. Which version\n> > > of submodule C would you demand to have when submodule A wants version C0\n> > > and submodule B wants version C1 of it?\n> > \n> > Right, in the discussion so far it seemed like henri seems to be the only\n> > user who is wanting an exact match, and he says he needs to see these\n> > inconsistencies. But I think he can modify the \"version xxx or newer\" to\n> > his needs without imposing these inconsistencies on users (like me) who\n> > don't want to see them.\n> \n> And I imagine if a submodule has such hints we could add a command say\n> \n> \tgit submodule resolve-dependencies\n> \n> which could resolve such \"I need a version newer than\" hints given by a\n> submodule to help the user to update a submodule in the superproject.\n> \n> Disclaimer: I think we need to think about all the implications such a\n> scheme introduces very carefully. The picture is still a bit blurry for\n> me.\n> \n\nAs I see it if you want a command like\n\"git submodule resolve-dependencies\"\n\n - the process need to decide if it will chose te lower version above\n all requierments or directly the head.\n - if one or more say I want exactly this version and it is not\n satisfied we need at least a warning.\n - We need to issue an error if all the required version can not be\n found in the same branch.\n\n\tHenri\n"},{"id":"172939","messageId":"4E3ADAD0.1060800@web.de","threadId":"27708","inReplyTo":"1312410562.3261.1030.camel@Naugrim.eriador.com","subject":"Re: tracking submodules out of main directory.","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-08-04T17:45:52Z","receivedAt":"2011-08-04T17:45:52Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 04.08.2011 00:29, schrieb henri GEIST:\n> Le mercredi 03 août 2011 à 23:30 +0200, Jens Lehmann a écrit :\n>> Am 03.08.2011 21:41, schrieb Junio C Hamano:\n>>> Jens Lehmann writes:\n>> But when you fetch a new version of Gimp into your submodule, it would be\n>> really nice if the superproject could be notified that the Gimp developers\n>> updated to 1.2.4 of Glib and inform you that an update of Glib might be\n>> appropriate. That could avoid having you to dig through compiler errors to\n>> find out that the new foobar() function from Glib 1.2.4 is needed (and if\n>> you need to pull in a bugfix in Glib, you might notice that *a lot* later\n>> when you forget to do that).\n>>\n> \n> Exact, I am really happy to read this.\n> And better do not bother to have the suproject.\n\nI don't get this, you can't get rid of the superproject.\n\n> cd to gimp directory, type git status it can tell you every thing and\n> when your satisfied you just have to type make.\n> At this point the superproject have not any use. \n\n\"git status\" inside the submodule won't tell you anything about the\ndependencies, but a \"git status\" in the superproject should. The submodule\nshouldn't know where exactly the submodules it depends on lives, that is\nthe decision of the superproject, not the submodule.\n\n>>>> In addition to that, it can (but mustn't) specify any of the following:\n>>>\n>>> I am guessing you meant \"does not have to\", instead of mustn't, here...\n>>\n>> Sure, thanks for deciphering that.\n>>\n>>>> a) Of this submodule \"foo\" I need at least that version because I won't\n>>>> compile/work with older versions of that. (this can be tightened to\n>>>> \"exactly that version\" to give henri the behavior he wants, but that\n>>>> should be policy, not mandatory)\n>>>\n>>> The \"loose collection of projects\" approach like that has its uses, and it\n>>> is called \"repo\". Why re-invent it? The behaviour Henri wants to specify\n>>> the exact version is how git submodules work already, so I do not see\n>>> there is anything to be done here.\n>>\n>> Let me make this clear: this is not about changing how submodules are\n>> committed in a superproject. It is not about having a loose collection of\n>> projects, they stay tied together in a defined state by the superproject.\n>>\n> \n> Yes but for me, from when I started this this topic, it was all about\n> having a loose collection of project with dependency references between\n> them. And get rid of the superproject.\n> It is my first and only goal.\n\nBut I fail to see how that would improve anything.\n\n>> Henri wanted it a bit upside down: any submodule could request a certain\n>> version of another submodule somewhere else in the repo. And he wanted to\n>> use gitlinks from one submodule to another for that, which I - hopefully -\n>> convinced him was no good idea.\n>>\n> \n> You just convince me that submodules are more than I need and to make a\n> lighter independent version of submodules which will never been followed\n> by git commands.\n\nSubmodules are what you need, but it's no use to implement dependencies by\nusing gitlinks that point outside of their repositories.\n\n>>>> b) And if you don't know where to get it, use this url\n>>>\n>>> Again that is the job of .gitmodules in the superproject.\n>>\n>> Yes. But this idea is about how the url could get into the .gitmodules of\n>> the superproject in the first place. That can make it easier for the\n>> superproject's developer to import a submodule into his repo and much more\n>> important: it makes it possible to pull in submodule dependencies\n>> automatically e.g. when running \"git submodule add --resolve-dependencies\n>> Gimp\".\n> \n> Only if you have a superproject.\n> If not do the same thing from the gimp repository, now it contain all\n> necessary infos to do the job.\n\nNo, it doesn't. Apart from the Gimp project telling you what version it\nwants, you need to have a place to record the version that the user really\nused. And that won't work without a superproject.\n\n>>>> That is all stuff the submodule knows better than the superproject.\n>>>\n>>> Not necessarily. The version A0 of submodule A may depend on submodule B\n>>> and may also know it must have at least version B0 of that submodule, but\n>>> the superproject would know other constraints, e.g. the superproject\n>>> itself also calls into submodule B and wants a newer version B1 of it.\n>>\n>> Right. That's what I tried to explain to Henri, the superproject ties it all\n>> together. But I also like his idea to add a way to communicate information\n>> from the submodule to the superproject, and give the superproject a choice\n>> if it wants to use it.\n>>\n> \n> yes but the superproject contain no code in your design.\n> Then it will never need anything by itself.\n> It is only a container which you will inform with data already known by\n> the submodules I do not see any value to it.\n\nBut being the container that ties it all together is more than enough value.\n"},{"id":"172947","messageId":"20110804200529.GA35398@book.hvoigt.net","threadId":"27708","inReplyTo":"1312410562.3261.1030.camel@Naugrim.eriador.com","subject":"Re: tracking submodules out of main directory.","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2011-08-04T20:05:30Z","receivedAt":"2011-08-04T20:05:30Z","isPatch":false,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"Hi,\n\nOn Thu, Aug 04, 2011 at 12:29:22AM +0200, henri GEIST wrote:\n> Le mercredi 03 ao??t 2011 ?? 23:30 +0200, Jens Lehmann a ??crit :\n> > Let me make this clear: this is not about changing how submodules are\n> > committed in a superproject. It is not about having a loose collection of\n> > projects, they stay tied together in a defined state by the superproject.\n> > \n> \n> Yes but for me, from when I started this this topic, it was all about\n> having a loose collection of project with dependency references between\n> them. And get rid of the superproject.\n> It is my first and only goal.\n\nIn that case maybe what you want is your own completely independent\nimplementation of a tool which manages a collection of submodules. I\ndoubt that tracking of submodules outside of the worktree will ever be\naccepted inside core git. Some dependency scheme which makes use of the\ncurrent submodule implementation could be a feasible way but you can not\nget rid of the superproject.\n\nYour approach introduces many problems which you were not able to\npresent solutions for. So if you really want to work on this I suggest\nyou try to implement your solution outside of core git first. If you can\nprove that you can solve all the immanent problems we can discuss\nintegrating it into git again.\n\n> > Henri wanted it a bit upside down: any submodule could request a certain\n> > version of another submodule somewhere else in the repo. And he wanted to\n> > use gitlinks from one submodule to another for that, which I - hopefully -\n> > convinced him was no good idea.\n> > \n> \n> You just convince me that submodules are more than I need and to make a\n> lighter independent version of submodules which will never been followed\n> by git commands.\n\nAs described above this is probably the best way for you. Maybe you can\nprove that such a tool works but git's submodules implementation can\ncurrently not really assist you with your approach.\n\nCheers Heiko\n"},{"id":"172959","messageId":"1312504178.3261.1417.camel@Naugrim.eriador.com","threadId":"27708","inReplyTo":"4E3ADAD0.1060800@web.de","subject":"Re: tracking submodules out of main directory.","fromName":"henri GEIST","fromEmail":"henri.geist@flying-robots.com","sentAt":"2011-08-05T00:29:38Z","receivedAt":"2011-08-05T00:29:38Z","isPatch":false,"sender":{"key":"henri.geist@flying-robots.com","avatar":null},"body":"Le jeudi 04 août 2011 à 19:45 +0200, Jens Lehmann a écrit :\n> Am 04.08.2011 00:29, schrieb henri GEIST:\n> > Le mercredi 03 août 2011 à 23:30 +0200, Jens Lehmann a écrit :\n> >> Am 03.08.2011 21:41, schrieb Junio C Hamano:\n> >>> Jens Lehmann writes:\n> >> But when you fetch a new version of Gimp into your submodule, it would be\n> >> really nice if the superproject could be notified that the Gimp developers\n> >> updated to 1.2.4 of Glib and inform you that an update of Glib might be\n> >> appropriate. That could avoid having you to dig through compiler errors to\n> >> find out that the new foobar() function from Glib 1.2.4 is needed (and if\n> >> you need to pull in a bugfix in Glib, you might notice that *a lot* later\n> >> when you forget to do that).\n> >>\n> > \n> > Exact, I am really happy to read this.\n> > And better do not bother to have the suproject.\n> \n> I don't get this, you can't get rid of the superproject.\n\nOf corse I can.\nI have done It the patch I have submit has been done for an do it\nsuccessfully.\nI am doing it every day.\n\nI have in the same \"directory\" not repository.\nTwo repository \"gimp\" and \"libpng\".\nI cd in the gimp directory.\nAnd do \"git add ../libpng\" and it is done.\nThe gimp repository track the \"../libpng\" repository by its path and\nsha1.\n\nI do not need anything else.\n\n> \n> > cd to gimp directory, type git status it can tell you every thing and\n> > when your satisfied you just have to type make.\n> > At this point the superproject have not any use. \n> \n> \"git status\" inside the submodule won't tell you anything about the\n> dependencies,\n\nOf corse It does if the repository add been add\nIt will just like any other submodules inside of the repository\nGit status is even unable to see the difference.\nEssential because there is no difference.\n\n> but a \"git status\" in the superproject should.\n\nYes but I have no and want not to have a superproject.\n\n> The submodule shouldn't know where exactly the submodules it depends on lives, that is\n> the decision of the superproject, not the submodule.\n\nWhy not in my case it is needed has in \"gimp.c\" I have\n\n#include \"../libpng.h\"\n\nIf the code need to know where is libpng why the repository should not\nknow it as well ?\n\n> \n> >>>> In addition to that, it can (but mustn't) specify any of the following:\n> >>>\n> >>> I am guessing you meant \"does not have to\", instead of mustn't, here...\n> >>\n> >> Sure, thanks for deciphering that.\n> >>\n> >>>> a) Of this submodule \"foo\" I need at least that version because I won't\n> >>>> compile/work with older versions of that. (this can be tightened to\n> >>>> \"exactly that version\" to give henri the behavior he wants, but that\n> >>>> should be policy, not mandatory)\n> >>>\n> >>> The \"loose collection of projects\" approach like that has its uses, and it\n> >>> is called \"repo\". Why re-invent it? The behaviour Henri wants to specify\n> >>> the exact version is how git submodules work already, so I do not see\n> >>> there is anything to be done here.\n> >>\n> >> Let me make this clear: this is not about changing how submodules are\n> >> committed in a superproject. It is not about having a loose collection of\n> >> projects, they stay tied together in a defined state by the superproject.\n> >>\n> > \n> > Yes but for me, from when I started this this topic, it was all about\n> > having a loose collection of project with dependency references between\n> > them. And get rid of the superproject.\n> > It is my first and only goal.\n> \n> But I fail to see how that would improve anything.\n> \n\nIt improve my life and the life of my team has developers everyday.\nAll my team agree on this point. In fact they asked me to implement it.\nBecause we used to have a superproject and it does not scale well. \n\n\nThe \"gimp\" team and the \"gqview\" team shares the libpng but at there\npoint of view they are not related they even not need to know that the\nother one exist. Then they will never share the same superproject. It\nhas no sens for them.\nThen in your model you will need a superproject by project.\nI think we should put all that you put in the superproject in the\nproject itself. Then there will be only one project by project.\n\nAnd if the dependency are not part of the superproject, this remove the\nburden of each team to redefine all the dependencies recursively in any\ndependency they have. has the original \"libpng\" team have done it in the\n\"libpng\" project and not in there own superprojec witch the can not\nshare.\n\n> >> Henri wanted it a bit upside down: any submodule could request a certain\n> >> version of another submodule somewhere else in the repo. And he wanted to\n> >> use gitlinks from one submodule to another for that, which I - hopefully -\n> >> convinced him was no good idea.\n> >>\n> > \n> > You just convince me that submodules are more than I need and to make a\n> > lighter independent version of submodules which will never been followed\n> > by git commands.\n> \n> Submodules are what you need, but it's no use to implement dependencies by\n> using gitlinks that point outside of their repositories.\n> \n\nSubmodules is not what I need.\nWhat I need is pointers to external repository tracked by git.\nSubmodule was to my eyes the logical tool to do it.\nAnd I had made a patch to enable the tracking of external repository\njust has they do for internal ones.\n\nYou convince me that you think prohibiting me to do so is a feature to\nyour eyes. Because gitlinks and submodules can do more than this and you\ndo not want those other things to work outside of the repository.\n\nThen I propose to cook a kind of \"my_light_gitlinks\" which do only that.\n\n> >>>> b) And if you don't know where to get it, use this url\n> >>>\n> >>> Again that is the job of .gitmodules in the superproject.\n> >>\n> >> Yes. But this idea is about how the url could get into the .gitmodules of\n> >> the superproject in the first place. That can make it easier for the\n> >> superproject's developer to import a submodule into his repo and much more\n> >> important: it makes it possible to pull in submodule dependencies\n> >> automatically e.g. when running \"git submodule add --resolve-dependencies\n> >> Gimp\".\n> > \n> > Only if you have a superproject.\n> > If not do the same thing from the gimp repository, now it contain all\n> > necessary infos to do the job.\n> \n> No, it doesn't. Apart from the Gimp project telling you what version it\n> wants, you need to have a place to record the version that the user really\n> used. And that won't work without a superproject.\n> \n\nthe version of \"libpng\" that the user really use is stored in his\n\"libpng\" repository !\nAnd tracked by every project depending on it.\n\n> >>>> That is all stuff the submodule knows better than the superproject.\n> >>>\n> >>> Not necessarily. The version A0 of submodule A may depend on submodule B\n> >>> and may also know it must have at least version B0 of that submodule, but\n> >>> the superproject would know other constraints, e.g. the superproject\n> >>> itself also calls into submodule B and wants a newer version B1 of it.\n> >>\n> >> Right. That's what I tried to explain to Henri, the superproject ties it all\n> >> together. But I also like his idea to add a way to communicate information\n> >> from the submodule to the superproject, and give the superproject a choice\n> >> if it wants to use it.\n> >>\n> > \n> > yes but the superproject contain no code in your design.\n> > Then it will never need anything by itself.\n> > It is only a container which you will inform with data already known by\n> > the submodules I do not see any value to it.\n> \n> But being the container that ties it all together is more than enough value.\n> \n\nIt has absolutely no value to have a git repository as a container.\nA simple directory will do it very well.\n\n\tHenri\n"},{"id":"172961","messageId":"1312510757.3261.1439.camel@Naugrim.eriador.com","threadId":"27708","inReplyTo":"20110804200529.GA35398@book.hvoigt.net","subject":"Re: tracking submodules out of main directory.","fromName":"henri GEIST","fromEmail":"henri.geist@flying-robots.com","sentAt":"2011-08-05T02:19:17Z","receivedAt":"2011-08-05T02:19:17Z","isPatch":false,"sender":{"key":"henri.geist@flying-robots.com","avatar":null},"body":"Le jeudi 04 août 2011 à 22:05 +0200, Heiko Voigt a écrit :\n> Hi,\n> \n> On Thu, Aug 04, 2011 at 12:29:22AM +0200, henri GEIST wrote:\n> > Le mercredi 03 ao??t 2011 ?? 23:30 +0200, Jens Lehmann a ??crit :\n> > > Let me make this clear: this is not about changing how submodules are\n> > > committed in a superproject. It is not about having a loose collection of\n> > > projects, they stay tied together in a defined state by the superproject.\n> > > \n> > \n> > Yes but for me, from when I started this this topic, it was all about\n> > having a loose collection of project with dependency references between\n> > them. And get rid of the superproject.\n> > It is my first and only goal.\n> \n> In that case maybe what you want is your own completely independent\n> implementation of a tool which manages a collection of submodules.\n\nIf I make a tool to managed a collection of submodules, it will became\nthe superproject I want to get rid of.\nI do not want to have any concept of a collection. And that is why I do\nnot want a superproject.\n\nI have no exhaustive list of project/modules/submodules.\nOnly some independent projects witch knows if they need some others.\n\nThen I realy need the tool to be embedded in the repository.\n\n> I doubt that tracking of submodules outside of the worktree will ever be\n> accepted inside core git. Some dependency scheme which makes use of the\n> current submodule implementation could be a feasible way but you can not\n> get rid of the superproject.\n\nI can not but have already done it.\n\n> \n> Your approach introduces many problems which you were not able to\n> present solutions for.\n\nBut it does not break anything.\nAnd generate no problem for me.\nThere is only when you try to get one step more and try to use even more\nadvanced things than I do on top of it.\nAnd those problem also apply to normal submodules.\n\n> So if you really want to work on this I suggest\n> you try to implement your solution outside of core git first. If you can\n> prove that you can solve all the immanent problems we can discuss\n> integrating it into git again.\n> \n\nThat is what I had proposed to do by making a file .gitdependencies\nsimilar to .gitmodules and create shell script wrappers for :\n - git add\n - git status\n - git reset\n - git rm\n\nthe only thing is that with the previous patch I only had to touch \"git\nadd\" every thing else was already ready to handle it.\n\n> > > Henri wanted it a bit upside down: any submodule could request a certain\n> > > version of another submodule somewhere else in the repo. And he wanted to\n> > > use gitlinks from one submodule to another for that, which I - hopefully -\n> > > convinced him was no good idea.\n> > > \n> > \n> > You just convince me that submodules are more than I need and to make a\n> > lighter independent version of submodules which will never been followed\n> > by git commands.\n> \n> As described above this is probably the best way for you. Maybe you can\n> prove that such a tool works but git's submodules implementation can\n> currently not really assist you with your approach.\n\nWe will see.\n\n\tHenri\n"}]}